The book consolidates almost everything I wrote about AI on this blog from February to October 2026: all the experiments, the Frank projects, the benchmarks, billions of tokens spent and hundreds of hours of work over eight months, reorganized into a format that’s easier to read than a pile of dated posts. It came out in Portuguese and in English.

Important notice: this is a preview. The book is still in progress and new versions will come out until I consider it done. If you find anything wrong, from a typo to a fact, open an issue on GitHub. The trail I describe below exists precisely so that the fix reaches the right paragraph.

This text is about the technical backstage. How you turn 131 blog posts, written over months, with opinions that changed along the way, into a book with a beginning, middle, end, appendices, glossary and bibliography. And how you do that with agents without losing control of what the book says.

What’s inside

Five parts, each answering a question people keep asking me:

1. What is this thing, anyway. Is it intelligent? Is AGI coming?
2. The marathon. Does it actually work, or is it all demo?
3. Numbers and propaganda. Which AI is best? Can you believe the announcements?
4. Who keeps the keys. Is it dangerous to let it touch my things?
5. And my job? Will it replace me? What comes next?

That’s 20 chapters and two interludes, plus a preface, a “how to read”, a “before you start” saying what the book doesn’t explain and where to learn it, an epilogue and an afterword. Then come ten appendices (the machine inside without math, further reading, how to study with AI at your side, three bubbles, a timeline, a minimal kit for using agents safely, ai-memory, how to read a benchmark or an announcement, the year’s projects, and the backstage for programmers), the sources, the image credits, a glossary of almost 150 terms and more than 300 references in ABNT style. The print edition passes 500 pages at 6 by 9 inches; the screen edition, around 475. There are more than 50 figures, all with a provenance record.

The audience is different from the blog’s. The book was written for people who are anxious or confused about AI: the professional afraid of being replaced, the parent who read that AGI is two years away, the manager being sold an “AI transformation”. Most of them don’t program. That changes the voice, and I’ll come back to it.

The problem: half a million words that disagree with each other

On October 12 I published the year’s synthesis, which became chapter 20. On the 13th I started the book. I had 131 posts from 2026 on the blog, almost half a million words, from model benchmarks to a bitcoin wallet.

Reorganizing that by hand would take months. And there’s a worse problem than volume: I changed my mind during the year. I redid the benchmark several times, corrected costs, switched tools, and a February post contradicts a September one with complete naturalness. A book that simply pasted the posts in order would be a book that contradicts itself.

So I did what the whole book describes: I handed the grunt work to coding agents and kept the part of deciding, building the process and checking. The process is the subject of this text.

Step 1: a sealed inventory

The first thing was a script that reads the 131 posts and records, for each one, the SHA-256 hash of the Portuguese file and of the English file, plus the exact commit of the blog repository everything was read from. If a comma changes in a post, the hash changes with it. That file is machine-generated and never edited by hand.

Then an agent read each post and filled out a fixed form, with a schema defined in YAML: the thesis in one or two sentences, the claims a book would need to verify, which of them age fast, which lay reader’s fear the text answers, what to cut. Each analysis carries the hash of the post it came from.

Of the 131 texts, 96 had AI as the central subject or with relevant weight. The others only came in when they taught something specific, and every AI post left out has its reason recorded in the structure file. A script fails the structure if any AI post is left without a destination.

Lineage: who supersedes whom

To solve the contradiction problem, there’s a lineage map. It says which post superseded which, what can still be salvaged from the older one, and which corrections coming from the reference projects (the benchmark repository, ai-memory’s, ai-jail’s, my home server notes) apply to each text.

The rule for chapters is to tell the most recent state and, when the change teaches something, tell the change. “In June I thought X; in July the numbers said Y” is a story. Printing the old number as if it were current is an error, and the checker treats it as an error.

Step 2: the structure is data, and it generates the configuration

From the analyses came a proposed structure: five parts, each answering a reader’s fear, twenty chapters, two interludes. I read it, changed it and approved it. Some pieces came in at my request, like the “before you start” and the appendix on the machine inside.

That structure lives in a single YAML file, and it’s the source of truth. Each chapter has its id, title, opening scene, the question it answers, the arc, the list of source posts and the figure ideas. The Quarto configuration, which assembles the book, is generated from that file by script. Nobody edits the configuration by hand.

This matters because structural change is where a book breaks. Midway I moved the cut-off: the January posts went out, and the story settled between February and October. Ten posts vanished from the base.

Three chapters needed a new scene, a dozen units needed small repairs, and the damage that’s hard to see was elsewhere: a sentence in an untouched chapter saying “the five reviewers from chapter 5”, the timeline, the projects appendix, chart labels, every translation. That’s why there’s an impact script that, before any edit, lists every paragraph, figure, reference and translation that depends on a post.

Step 3: a pilot chapter becomes a contract

Before scaling, a pilot chapter. I picked chapter 5, about the first ten percent of a project, and it served to calibrate the voice and discover the doubts an agent would have along the way. Each doubt resolved became a written rule.

Those rules went into a contract document every agent reads before writing, along with three things:

• the book’s voice guide, which inherits the blog’s rules (my WRITER.md, the humanizer and my finishing checklist) and only adds what changes when the text leaves a dated post and goes into a book a lay reader holds in their hands;
• a continuity file, saying which chapter explains each concept and what each character is called, so nobody explains “context window” five times;
• the entire structure, so each agent knows what the other chapters cover.

Besides the voice rules that already existed (a chapter opens on a scene with a date, a place and something at stake, never on a definition; it closes on a hook toward the next one, never on “in this chapter we saw”), some of the rules that came out of the pilot, to give you a taste:

• when the chapter brief and the post disagree on a detail, the post wins;
• the chapter that owns a concept explains it properly; if the term shows up earlier in reading order, it gets a half-sentence gloss and a pointer, never a second explanation;
• a fact verified online gets a citation even if the original post had no link;
• model and product names in the vendor’s spelling, even when the blog abbreviated them.

It’s the project instructions file I describe in the chapter about how to talk to the machine, at the scale of a book. Anyone who has written an AGENTS.md for a codebase recognizes all of it.

Step 4: parallel drafts, contradictions expected

With the contract ready, the chapters were drafted in parallel, one agent per chapter, in two waves: parts I and II first, then III through V, so the later chapters could build on the earlier ones. Each agent received its chapter’s brief, the analyses, the full posts, the lineage and the reference-project files it needed.

Agents working at the same time contradict each other, and that happened. One chapter said FrankMD had around 130 commits in three days; another, that it had 212 in 19 days. Both numbers came from the posts and were right, they were just different windows. An integration ledger collected those conflicts, and the rule became making the window explicit in each chapter.

After the drafts comes the integration pass, with another set of agents, each owning a group of chapters and forbidden from touching the others. Their job: apply the conflict ledger, cut concepts explained twice, check that every callback matches what the other chapter actually says, make sure the last paragraph of a chapter leads into the first of the next, and redo the fact-check assuming the draft is wrong.

To read the seams, the build generates a “seams” file: the final paragraph of each unit next to the opening paragraph of the next. It’s the fastest read there is for finding where the book stops feeling like one book.

Step 5: an invisible marker per paragraph

This is the part I find most useful in the whole project. Every paragraph of the book, in the source file, carries a comment saying where it came from:

<!-- src: 2026/09/28/llms-sao-boas-em-reproduzir-o-que-existe-e-coisas-novas -->
Every LLM was trained only on what is public...

<!-- src: original -->
New text, written for the book.

<!-- src: ref:ai-jail/README.md -->
Fact checked in the reference project.

The marker disappears when the book is built, through a Pandoc Lua filter, so the reader never sees it. It exists for maintenance. I edit posts after publishing all the time, and the book has to follow.

The rake drift command redoes the inventory, compares the hashes, and lists the chapters that depend on a post that changed, with the post’s diff since the commit at which the book last read it. The marker leads straight to the paragraphs that came from that post, and only those need review. Once resolved, a script records the new hash and the commit.

A real example, from today. I removed from the reverse engineering post a paragraph about a Linus Tech Tips video. drift flagged chapter 19 and one appendix; the diff showed that passage had never been used in the book; two commands later, both were stamped with the new hash. Without the marker, I’d have had to reread two chapters to discover I didn’t need to change anything.

The bibliography plays the same role for external sources: each reference records which post cited it. And each image has its own provenance record.

Step 6: what the fact-check caught

Every number, date and name was checked against three oracles: the posts, the reference projects and primary sources online, with the same adversarial checker prompt I use on the blog’s articles. The full list is in the book’s afterword, and a good part of the corrections are to my own blog:

• in the March review of the Strix Halo mini-PC, I had set aside 96 GB of memory for the GPU; in April I lowered it to 64, and later posts still said 96. The book uses 64 for everything after April;
• a counting bug in one of the benchmark’s tools undercounted by 40 to 90 times the cost of runs made on it before August. The book cites none of those costs;
• in the June text about Claude Fable 5, I wrote it cost ten times more than Opus 4.8 per run. Redoing the math in July, with cache-read tokens included, Fable cost almost double. The post still says ten times; the book tells the wrong number and the correction;
• in a March text, I wrote that Anthropic had bought Bun at the end of 2024. The announcement is from December 2025;
• a chapter summary, written by an agent, said Claude Code’s subscription lock fell in less than a day after the leak. The announcement came about 30 hours later, and the book says “the next day”.

The drafts came out fast. Confidence in the text came from the checking. And the source beats the summary, even when the summary comes from the machine.

Step 7: a chapter with an error doesn’t pass

On top of everything runs an automatic checker, the equivalent of continuous integration. They’re Ruby scripts, standard library only, chained in a Rakefile, plus what they call externally: the chart checker is Python because it lives inside matplotlib, the page audit uses poppler, and epubcheck needs Java:

• a chapter linter fails em dashes, phrases banned by the voice guide, loose URLs in the middle of prose, unknown citation keys, paragraphs without a provenance marker, and warns about overlong paragraphs;
• a doctor checks that every cross-reference, citation, glossary term and figure exists, that provenance matches the inventory, that no post before the cut-off leaked in, that translations are up to date, and runs a callback heuristic: a sentence pointing at another chapter using names that chapter no longer contains;
• a page audit opens the finished PDF and looks for blocks split across pages, headings orphaned at the foot of a page, nearly empty pages, oversized images, lines overflowing the margin;
• a chart checker looks for labels that spilled out of their boxes;
• epubcheck validates the EPUB 3;
• a style report for copyediting: passages repeated across chapters (an inevitable consequence of posts that repeat the same thesis from different angles), recurring phrases, overused words, term variants, badly formed comparatives in Portuguese.

And the scripts have tests. A suite of almost 170 tests builds a fake book in a temporary directory, with five fake posts in a fake git repository, and checks that each tool catches the problem it should catch. When a bug is fixed, the test that would have caught it goes in, with a comment naming the regression it guards. It runs in CI before every build.

The assembly pipeline

The toolchain is Quarto, which bundles Pandoc and Typst, version-pinned inside the repository. No LaTeX. A single rake build produces, from the same tree of Markdown files:

Portuguese and English are Quarto profiles, generated from the same structure file. Citations come from a YAML in CSL format shared by both editions, with an ABNT style adjusted for Portuguese. The glossary is a Lua filter: each term is marked in the source where it appears, and the filter links the mark to the entry, expands the acronym the first time and generates the page.

Typst solved something I thought would cost me weeks: a PDF that looks like a typeset book, Portuguese hyphenation, ligatures, without the pain of TeX. The page audit after the build catches what the engine let through, and a rake fit recompiles while tightening chapters that end on a nearly empty page.

The figures

Every figure is code or has a record. Charts and box-and-arrow diagrams are matplotlib scripts, 43 of them, each with a note of the chapter the data came from, and with the labels in Portuguese and English inside the script itself: the same chart comes out in both languages. The path for D2 diagrams exists in the repository, and no figure in the book needed it.

The conceptual illustrations were generated by AI, with the model, the prompt and the date of each one recorded in its credit record, and the book discloses it. The rule I imposed on myself: no AI-generated image of a real person. Real people only appear in freely licensed photos, with the credit in the caption.

The cover is the retro-futurist robot with the weary face, kneeling at a 1950s World’s Fair, studying its own hand while the crowd watches. The prompt to the model described the scene to hold three fears at once: the end of humanity, losing your job, the machine becoming conscious. The cover’s record keeps the whole prompt. The face is Marvin’s, my newsletter’s character, and a sticker with my face sits beside the name.

The tricks of turning posts into a book

Turning a blog into a book is a list of mechanical conversions, and each one has a catch:

• A link becomes a citation. Every external link became a bibliography entry, and the sentence has to stand without the link. A link to another post of mine became a cross-reference to the chapter that now covers it, or disappeared. Never a URL in the prose.
• “Today”, “yesterday”, “last week”, “update:” became absolute dates. The book will be read in 2028 too.
• Model versions, prices, benchmark scores stayed as dated snapshots (“in September 2026, the best…”), and when a later post superseded the number, the book tells the change instead of printing the old number.
• Code dumps, install steps, terminal screenshots were cut. At most a 3-to-8-line excerpt when the code is the point; the step-by-step went to an appendix.
• Post titles, which are made for search (“Vibe Code: I built X in two days”), became short literary titles, with the subject in the subtitle.
• Repetition across posts, the same thesis from many angles, is said once, in the right place, and later chapters build on it.
• Calls to action, “subscribe”, “comment”, cut.
• The sharp edge aims at the propaganda, never at the reader. The post “You’re an idiot if you believe…” became a chapter about how the ads work. The reader who believed the ad is the person the book wants to help.
• Every technical term is explained once, at its first appearance in the book, and goes to the glossary.

And the most important of all: the book reads like a first-person story, with the year as its spine. Information arrives when the narrative needs it, instead of following encyclopedia order. That’s the opposite of how a blog is written, and it was the rule that gave the agents the most trouble.

The English edition

The English edition, Competent Enough, only started after I approved the Portuguese one. Each translated unit records the hash of the Portuguese file it came from, and wherever the book follows a post of mine that already had an English version on the blog, the translation uses my own English wording instead of translating again.

drift also works per language: if I change a paragraph in Portuguese, it flags the English unit that went stale, and only the marked paragraphs are retranslated. Charts with text are regenerated in English from the same scripts, and the English cover is composed by script on top of the same art.

Releasing is pushing a tag

A release is a CHANGELOG entry and a git push of a vX.Y.Z tag. A GitHub Actions workflow runs the tests, builds both editions in every format, validates the EPUB, runs the audit and publishes the release with the files. It deletes every release except the two newest, and keeps the tags. That’s how the official page always points at the current version.

The repository is public, and that brought its own catch: my home server notes are the source of some facts, and they’re private. The provenance markers cite those files by alias, the alias map stays out of git, and a pre-push hook blocks any file or commit message containing a private repository name, host or IP.

Copyediting: what the checking machine lets through

Lint, doctor, page audit and tests catch structural problems. They let through what a book written by many agents, each seeing a few chapters, always suffers from: the same sentence or anecdote reused in three chapters, drifting tone, inconsistent terminology, agreement slips. For that there’s a copyedit procedure, which runs once per version, in three steps from the cheapest to the most expensive.

Step 1, mechanical and nearly free: the style report I mentioned above. Sequences of seven words or more that appear in more than one unit, meaning reused sentences and retold anecdotes; set phrases of four to six words used in many chapters, which are nice as callbacks and become tics when they repeat; a word used far more in one chapter than in the rest; term variants (“e-mail” and “email”, “Open AI” and “OpenAI”); and an agreement heuristic for Portuguese. The report is a worklist, and nothing changes on its own.

Step 2, the straight-through read: one read-only agent per part of the book, each reading its units in order, start to finish, with a shared style sheet (names, spellings, terms, recurring phrases from step 1). Each produces a ranked report, editing nothing: typos and grammar first, then inconsistencies with the style sheet, repetition the reader would notice, passages a lay reader would stumble on, and pacing only in the worst cases. A script validates the reports, checks that every quoted passage really exists in the unit, numbers the items and summarizes.

Then comes the triage, done by me with an editor agent, and the pointed application of each approved item, under the same rules as the integration pass. A cheaper model does the proofreading; hard passages go to the strong model. Rough budget: two to three million tokens per language.

The most important rule of that step is “facts get checked, not asked”. Any item that turns on a number, date, name or tool behavior is settled by the editor against the source of truth before it reaches me: first the post pointed to by the paragraph’s provenance marker, recomputing totals; then the code or data behind the claim, in my repositories; then public records.

When two sources disagree, the task is to find out why. “653 commits in 8 projects” versus “692 in 4” were two cuts of the same work, one of them without the newsletter’s private repository, and the text now states its scope instead of picking a number. When the blog post itself is wrong, the book prints the correct figure and the error goes to a blog errata list, for me to fix at the source.

Only what no source can settle reaches me: an unpublished fact, intent (“is this ironic?”), a preference about a cut or a title, and a contradiction between two statements of mine with no record to break the tie. Each question comes with what was checked and what was found.

Step 3, my own read. The last and the most valuable. The notes go into the same cycle of apply, check and propagate to the English edition.

The first round of that copyedit is what separates preview 2 from preview 3. Among what it caught: commit counts now state their scope, a “more than a thousand” that summed to 984, the Frank Investigator voting example that didn’t match the code (figure redrawn), the David Sacks and Pirate Wires quotes in chapter 14 verified against the originals and corrected, Sam Altman’s photo swapped for one from 2025. And in the English edition, a reader pass of its own after the re-sync: Portuguese calques rewritten, glossary terms used consistently, American quotation punctuation throughout.

Fake readers, real feedback

Copyediting checks the text. It lets through the question that matters in a book for lay readers: can the person I wrote it for read it to the end, understand it, and come out convinced? To answer that, the next pass was a review by simulated readers.

The book’s preface has a section called “Who I wrote this for”. From it came five personas, each with a name, an age, a job and the fear that brought them to the book:

• Marina, 38, an accountant in Belo Horizonte, read that her job “ends in two years”, reads on her phone at night and wants to know what to do on Monday;
• Roberto, 52, owns a hardware store, his 15-year-old saw a video about superintelligence and asked if it was true; suspicious of hype, of “experts” and of an author who shows off;
• Carla, 44, operations manager at a logistics company, the board hired consultants selling an “AI transformation”; she wants a decision she can take;
• Lucas, 24, a junior developer a year into the job, afraid he chose the wrong career;
• Helena, 61, a retired history teacher, no fear at all, came for the stories and loses patience with lists and manuals.

One agent per persona, read-only, cheaper model, reads the whole book in order the way that person would. The instruction is explicit: you are a reader, the editor stays out of it; comma errors were already handled, report only what changes the reading experience. Each one returns a 1-to-5 score per chapter, a comment in the persona’s voice (“I finally get why the chatbot agrees with me”, “lost me in the benchmark tables”), at most 35 annotations classified as confusing, boring, rewrite or logic, and cut candidates. It costs about 350K tokens per persona per full read.

An editor consolidates: the score matrix by chapter and persona and the pattern behind it, what readers loved (to protect in any edit), the logic items, checked against the text and the posts before making the list and fixed regardless of votes, and the clarity items ranked by how many personas raised them. A single persona’s taste note is dropped. Then I decide, and recurring patterns become numbered rules in an editorial rules document, with their origin and how each is enforced.

The first read said what I suspected and gave it a measure: stories and practical tools work for everyone; the measurement-heavy middle, chapters 11 to 13, loses the non-programmers, averaging between 2.2 and 2.4. “Sharp when he tells what happened to him, loses me when he tells what he measured”, Helena summed up, for all five.

And all five caught the same argument flaws. Chapter 20’s conclusion went beyond its evidence: it said “the numbers say it won’t get smarter” resting on a programming benchmark the same chapter calls saturated. Chapter 9 argued in a way that can never lose: every agent failure was the request’s fault. Four of the five were sent to the wrong chapter by “how to read”.

Those became the first rules:

• every claim scoped to what was measured;
• no argument that can’t lose;
• opinion marked as opinion;
• the opposing side in its strongest form before rebutting;
• the book obeys its own lessons.

One round is not enough, because edits fix the old problem and create the new one. In round two, an apology placed next to a contradiction (“I know this seems to clash with…”) made all five readers notice a contradiction that three had previously missed. It became a rule: fix the design, and leave the apology out. So the process runs in rounds: read, edit, read again with the same personas on a fresh read, forbidden from opening the previous reports to avoid anchoring, and a script compares the rounds.

The average score is noisy (an untouched chapter swings 0.6 between reads), so the stopping criterion is different: the problems flagged stopped coming back and nothing new reaches three readers. In round three the curve flattened and the review stopped there, with a backlog for my own read. What changed along the way: about 8,000 words of lab notebook left the chapters for a new appendix, “For programmers: the backstage”, each paragraph carrying its provenance marker along; the reading list became an appendix; the Genesys PI section was parked, kept outside the book while verification is pending; chapter 19 got the title its argument supports; every chapter opens by orienting the reader before the first jargon; and the epilogue got a “this week” list per reader type. Cost of the three rounds: about 5 million tokens of reading plus about 3 million of editing and English re-sync.

The narrator got a past

With the argument in place, the first person lacked substance. The book’s narrator was the Akita of 2026, and I have thirty years of history that explain why I think what I think: the dot-com crash seen from inside, five years integrating SAP at large companies, the warnings about the hiring bubble I gave on video in 2019, 2020 and 2022, the “Don’t outsource your decisions”. All of it is in the transcripts of the 149 episodes of Akitando, published on this blog between 2018 and 2023.

The process was the same as the rest of the book, in miniature. Extraction agents read 23 episodes in full, with a form: biographical facts with the verbatim quote and what would verify them, facts about the world, recurring positions in my words, and hooks, meaning the exact place in the book where one or two sentences of that history back a 2026 claim. From that came a narrator profile, which I confirmed line by line, and a plan with about 30 touches, most of them one to three sentences.

Before any touch, more than 140 claims taken from the episodes went through the fact-check. It corrected the book and corrected me: the hiring bubble started around 2010, with interest rates near zero, and my February post said 2014; the dot-com bubble burst between 2000 and 2002; the 2022 layoffs were around 165 thousand. And it found errors in old episodes the book doesn’t even use, which went to a blog errata list.

The touches went where experience becomes evidence: the week in 2001 when my dot-com closed and a mentor called me into an SAP consultancy; the SAP years behind the claim that the model is blind to a company’s private rules; the dated bubble warnings next to the admitted mistake, because in 2022 I expected a second leg down in 2023 that the AI wave cancelled. Two new appendices came out of it: “Three bubbles”, with the verified numbers of the dot-com crash, the zero-interest bubble and the AI wave, and “How to study with AI at your side”, from the channel’s most watched episode.

Those episodes are background sources, and drift now watches them as it watches the 2026 posts. Then came a scoped check with the same five personas, only on the touched chapters, with three extra questions: does the narrator’s history make the argument more convincing, and where? Does any passage read as showing off or “I told you so”? Does anything about the narrator contradict itself?

All five said yes to credibility, with a condition: the history convinces when it’s evidence the reader can check, the dated warning next to the admitted mistake, and convinces less when it becomes a résumé, which clashes with the book itself, which says “a résumé is not an argument”. It became rule 21: the narrator’s history comes in as evidence, and credentials stay out.

Three or four readers flagged the same lines as showing off, and they went: “The warnings have dates”, “more than thirty public repositories”, “the most watched on my channel”. The self-deprecating lines and the admitted mistakes all counted in my favor. And the check found contradictions I hadn’t seen myself: the preface said “late 90s” and chapter 18 said 1996; one chapter said “eight months” and another “a year of daily use”, and they were fixed one by one.

Accessibility is part of the build too

An EPUB opening on a Kindle does not make it accessible. This book has dozens of diagrams, charts and tables. Without additional work, much of the argument simply disappears for anyone using a screen reader.

The pipeline now treats accessibility as a publishing contract. Each of the 55 figures, in both languages, has a short alternative text and a complete description of what the image communicates. In HTML and EPUB, the detailed description appears with the figure; in PDF, it becomes its semantic replacement without changing the layout. Tables have captions, and the EPUB now identifies where the main text, glossary, references and image credits begin in its semantic navigation. The authoring contract is documented in the repository.

This doesn’t depend on my memory either. rake check rejects figures without both descriptions or with overly long alternative text. Every build validates both EPUBs with EPUBCheck, DAISY Ace and the project’s own checks. The Kindle edition also goes through a cleanup of CSS and embedded icons that tend to cause problems in Amazon’s readers, but the script refuses to remove any rule the content has come to depend on.

No automated tool can certify WCAG conformance or guarantee how every reader on the market will behave. Manual review remains mandatory. The difference is that accessibility is now part of the build, and every change has to preserve that contract.

What remains mine

The repository records the first commit and the draft of every chapter on the same day, October 13. Those are the first ten percent, the ones that impress and say almost nothing about the rest. The other ninety percent are reading, cutting and correcting, and that part is mine. No chapter goes in without me reading and approving it, and what I send back to be redone goes through the same process.

Any of the good models of October 2026 would have written similar drafts, because the model became a commodity. What made the process work was what surrounds it: the inventory, the written contract, the automatic checker, the sources as oracle, the per-paragraph trail. It’s the same old software engineering I defend in every chapter, applied to text.

The agents were competent enough to write the draft. Deciding what it said remained my job.

And, once again: making a book with AI isn’t a “write me a book” prompt and done. I had to invent the whole process and steer the agent to create every piece of it: the scripts, the tests, the consolidation of the posts, the narrative strategy, the goals, what stays and what goes, the copyedit, the fact-checking, the automated release. You need to know exactly what you want, and then the AI helps a lot. Whoever doesn’t know what a book publishing process involves won’t make a real book, and showing that was one of the goals I had when creating this example.

Download it, read it, and tell me where I was wrong

Both editions, straight from GitHub, no sign-up. The current version is the final 1.0.0, from October 17, with everything this text describes:

The latest version, always, lives on the book page and on the GitHub releases.

It’s a preview. There will be mistakes, and the process above exists so they get fixed in the right place. Found one, open an issue.

That was the week on X, and if you only read headlines, it’s a reasonable conclusion. This text is for anyone who wants to know what each of those things actually does.

It blew up on the 9th, when the account below summed up what Brandon Thomas, a developer from Atlanta, had been publishing since late September: seven open source clones of Adobe’s main products, written in Rust with help from Claude Opus 5.5. Photoshop, Illustrator, Premiere, Lightroom, After Effects, InDesign, Acrobat. All free, all “clean room”, without a single line of Adobe code. This is the post that went viral:

AI is now being used to recreate Adobe's software, a developer has released seven free, open-source apps as clean-room alternatives to Adobe's main tools:

- PhotoCraft → Photoshop
- VectorCraft → Illustrator
- FilmCraft → Premiere Pro
- LightCraft → Lightroom
- EffectCraft → After Effects
- DesignCraft → InDesign
- PrintCraft → Acrobat Pro

Built in Rust with help from Claude Opus 5.5, they run on Windows, Linux, and macOS under MIT/Apache licenses without using Adobe's source code.

— Pirat_Nation (@Pirat_Nation) October 9, 2026

The same week, REA, “Reverse Engineer Anything”, passed 100K stars on GitHub, gaining tens of thousands a day. The pitch on its page: “see a feature in an app that you want in your own product? Ask your agent to investigate it with REA and build a version for your project”.

And anyone who follows retro gaming knows 2026 is the year that keeps on giving. There’s a community spreadsheet trying to list the unofficial PC ports, around 100 games from Ship of Harkinian to Skate 3, and it’s always behind. The Video Game Esoterica channel publishes a new port almost daily: Time Crisis decompiled from the arcade board, Daytona USA, Bloodborne.

The Xbox One version of Forza Horizon 2, stuck there since 2014, runs on Windows. AnyPS5 promises to convert PS5 executables into native PC binaries, and PS5 emulators like KytyPS5 and SharpEmu already run Astro Bot with actual gameplay. Much of it with AI in the loop, some of it openly vibe-coded.

Hence the consensus: programming, in general, is over. Every binary is reversible and reusable, just point the agent at it. My position is that it did get much easier, that it’s still nowhere near the silver bullet people imagine, and that the engine behind it, the LLM, stopped growing exponentially. The rest of the text is the reasons.

TL;DR: reverse engineering is a 40-year-old discipline with mature tooling, and AI sped up its grunt work, especially in retro, where the binary is available, tiny, and the target doesn’t move. The Adobe clones are alphas with hundreds of open bugs and pretty screenshots. REA is a toolbox that requires the binary in hand, Ghidra or IDA installed, and a lot of tokens. What’s worth money today doesn’t even have a binary: it’s SaaS, cloud, manufacturer partnerships and decades of color science. Rewriting Bun, with the project’s author and 64 agents, cost US$ 165K. Jump to the timeline, to REA, to the Adobe clones, to the Bun case, to why retro moves fast or to the answers at the end.

First of all: I don’t like Adobe

To be clear about where I’m speaking from. I hate Adobe’s business practices as much as anyone. I was a paying customer for years, used Photoshop and Premiere extensively, plus Lightroom and After Effects, and left for the same reasons everybody leaves: mandatory subscription, cancellation fees, prices going up with nothing in return.

And it’s precisely because I used them in depth that I know the size of what’s inside those boxes. Whoever thinks Photoshop is layers, crop and text never needed a color proof for a print shop, never opened a camera RAW whose color profile Adobe has maintained for twenty years, never did the conform on cinema footage, the work of gathering the camera’s raw material for finishing. I’ll get there, after the basics.

Reverse engineering wasn’t born last week

Every emulator you’ve ever used exists because someone opened up hardware, disassembled a binary, sniffed a protocol and, in some cases, broke cryptography. The discipline has case law, commercial tooling and decades of history. A condensed timeline, with the milestones that matter most:

• 1982 to 1984: Compaq reverse engineers the IBM PC BIOS, and in 1984 Phoenix sells a licensable BIOS built in a clean room, by a team that only read the specification. The PC compatible industry is born. Source.
• 1992: Andrew Tridgell creates Samba by sniffing SMB packets. The same year, Sega v. Accolade and Atari v. Nintendo establish in the US that disassembling code to reach functional elements is fair use (Atari lost its own case for another reason: it lied to the Copyright Office to get the source).
• 1993: Wine begins, which becomes the foundation of Proton and of every Windows game that runs on the Steam Deck today.
• 1999: UltraHLE runs commercial N64 games at full speed; bleem! emulates the PS1, Sony sues and loses the injunctions, and bleem! folds anyway in 2001; DeCSS breaks DVD protection.
• 2000: Sony v. Connectix rules that copying the PS1 BIOS to build an emulator is fair use.
• 2002 and 2003: PCSX2 and Dolphin are born, the two emulators that twenty years later are still the reference.
• 2007: the iPhone is opened eleven days after launch. The European Commission forces Microsoft to document its network protocols, and the Samba team receives the documentation for 10,000 euros.
• 2010: the fail0verflow group shows at 27C3 that Sony signed the PS3 firmware with a fixed nonce, exposing the private key (the nonce is the number that should be random in every signature). Days later, already in 2011, geohot publishes the key, Sony sues and settles in March.
• 2011 and 2013: RPCS3 (PS3) and Xenia (Xbox 360) are born, the two hardest emulators ever built, for reasons I’ll explain.
• 2019: the NSA releases Ghidra as open source. The Super Mario 64 decompilation leaks and goes public, and the PC port appears the following year.
• 2021 and 2022: Ocarina of Time 100% decompiled after almost two years of work; Ship of Harkinian becomes the reference port.
• 2024: Mr-Wiseguy releases Zelda 64: Recompiled, the first showcase of N64 static recompilation.
• 2025: Sonic Unleashed Recompiled brings the same trick to the Xbox 360, converting PowerPC to C++ and shaders to HLSL.

Notice that the current phase, decomp and recomp at scale, starts in 2019, well before any coding agent. AI joined an assembly line that already existed.

The tools

The tooling is mature too, and much of it is free:

• IDA Pro (Hex-Rays), the reference commercial disassembler and decompiler, from one thousand to almost nine thousand euros a year, with a free version limited to x86.
• Ghidra, the NSA’s open answer, with a decompiler and scripting, Apache 2.0.
• Binary Ninja, with a free edition and licenses from 200 to 3,500 dollars.
• radare2 and Cutter, the GUI for rizin, which is a radare2 fork: the open command line and the open interface.
• x64dbg and WinDbg on Windows, GDB everywhere else.
• Frida, to inject code into a live process and watch what it does.
• JADX for Android and ILSpy for .NET.

Keep this list in mind. REA, which we’ll get to shortly, is a wrapper around it.

How a binary gets taken apart, in practice

In principle, every binary is reversible. The processor has to be able to execute it, so the instructions are in there. The path is always the same:

1. Disassemble: the binary becomes assembly, one machine instruction per line. This is mechanical.
2. Decompile: the assembly becomes something resembling C. Ghidra and IDA do this reasonably well, with a lot of noise.
3. Recover what the compiler threw away: variable names, function names, types, structures, comments. None of it survives compilation. This is the real work, and it’s human.
4. Refactor until it becomes code a person can read, maintain and port.

The N64 decomp projects take step 4 all the way: their C code, recompiled, produces the original ROM byte for byte. That’s how Super Mario 64 became a project with 135K lines of game C code (around 100K of actual code, plus half a million lines of generated level and model data), and Ocarina of Time passed 430K lines. Static recompilation skips part of this: it translates the original processor’s instructions into generic C, without trying to understand them, and replaces only the parts that talk to the hardware. It’s faster and the result is less readable.

“But can’t the AI just read the binary directly?”

Someone always asks: if it’s AI, why go through C? Let the model read the binary and build on top of it. The short answer is that an LLM only knows what was in its training corpus, and a corpus of binaries paired with source code is scarce, because no human has written production assembly in decades.

The long answer is that the literature exists, and it’s instructive precisely because it’s modest. The lineage runs from 2018 neural networks to models like SLaDe (200 million parameters, one per architecture and optimization level), LLM4Decompile (up to 33 billion) and Nova. Meta published an LLM Compiler that translates assembly into LLVM IR. The best results, on isolated benchmark functions, hover around 60 to 65% of code that runs again and gives the same result, dropping sharply when the compiler optimized with -O3.

Two recent studies show the real state of things. DecompileBench, with 23K real functions, found that LLM-based decompilers produce more readable code with half the functional correctness of commercial decompilers. And a September 2026 paper measured that LLM refinement of Ghidra output raises the compilation rate from 75% to 90% and drops behavioral fidelity from 74% to 62%, with up to around 10% of functions with known vulnerabilities no longer reproducing the flaw, meaning the bug vanished without anyone asking.

Summing up what exists: small models, function by function, almost only x86-64 Linux, and the best ones are refinement layers on top of Ghidra, which keeps the classic decompiler in the loop. No emulator, no game, no whole program has been neurally recompiled. Until someone invents that, you work with reality, and reality includes the intermediate layer of programming language and compiler.

The AI assistants that exist for this in production confirm the design: aiDAPal, an IDA plugin by Atredis, Binary Ninja’s Sidekick, the MCP servers for Ghidra. All of them are an LLM naming variables and explaining functions on top of what the traditional decompiler produced.

What REA actually does

I cloned REA and read the code. It’s an MCP server and a TypeScript CLI that wraps the tools from the list above and exposes them to your coding agent: Ghidra, Hopper, IDA, JADX, Frida, Wakaru for obfuscated JavaScript, Playwright to capture what a website does. The agent asks, REA runs the tool and returns pseudocode, call graphs, strings and IPC traces, each result with an evidence record and a list of limitations.

I had already done that flow by hand, months before REA went viral. In July I had Fable 5 analyze the code of TikTok, Clash of Kings and gov.br: I downloaded the APKs, unzipped them (an APK is a zip), ran JADX on the .dex files and let the model read the Java that came out the other side. It was enough to see the endpoints, the permissions, the embedded SDKs and how each app builds the device fingerprint, that persistent identifier that survives clearing data and reinstalling. TikTok came out as industrial-grade collection, armored against auditing; gov.br, as the example of how to do it right.

The three lessons from that post apply to all of REA. Android is far too easy to decompile, and even so the result serves only static analysis, because recompiling the app is out of reach: the names come scrambled by obfuscation, resources and signing keys are missing. The most sensitive part lives in native code, .so files in C and C++, which decompile into nothing readable, and in TikTok that’s exactly where the core sits. And what came out of that work was a report on what the app does, with caveats, and no TikTok clone. REA packages that same flow into an MCP server; the walls stay in the same place.

The judgment is supplied by the LLM you already pay for. REA supplies the deterministic plumbing and the provenance. The phrase “automates the heuristics of reverse engineering”, which circulates out there, appears nowhere in the repository; the description the project itself uses is agent-driven reverse engineering with traceable evidence.

What it requires: the artifact on your machine (native binary, Electron app, .NET assembly, APK, firmware, network capture), Node 22.19 or later, and the heavy tools installed at your own expense. Ghidra is free; IDA, Hopper and JEB the README tells you to buy. There’s no REA API key because it runs locally, and the token cost lands entirely on your agent subscription.

And that cost is the detail nobody mentions. REA’s MCP tool catalog is 2.3 MB of JSON, which goes into the agent’s context. The project itself publishes an experiment in which analyzing SQLite compiled to WASM, on the default path, took 42 tool calls, five minutes and 300K input tokens. A full inventory of an Electron app like Obsidian returns almost 1 MB of JSON.

There’s an open issue complaining that inspecting an ordinary Mac app returns 80K to 230K tokens in one go.

The project is serious and goes far: six months, 2,600 commits, a thousand test files, version 6.4 released on October 11. It’s also unstable: 190 open issues, several breaking changes per minor release, subsystems marked experimental.

The limits are written in the repository itself. CONTRIBUTING excludes breaking DRM, anticheat, licensing and commercial protections. The DISCLAIMER warns that decompilation, reconstruction and AI-assisted analysis “may be incomplete or incorrect”. And even the internal instructions for generating the website’s figures say, in so many words: “never imply REA automatically clones a program” and “never say full reconstruction, exact game clone, or automatic source recovery”.

REA is a good toolbox for someone who already knows how to do reverse engineering and wants an agent holding Ghidra. It isn’t the “copy this app for me” button. The people who wrote the project are the first to say so.

PhotoCraft: pretty screenshot, alpha inside

The PhotoCraft repository was created on September 30. In two weeks, 54K stars, 8 releases and, as I write, more than 800 open issues. The README badge says “early alpha”, and Brandon Thomas himself, quoted by Gizmodo, said it’s nowhere close to ready. The press that tested it reached the same conclusion: Gizmodo called it a “glitchy, but real, Photoshop”, and OMG Ubuntu “a superficial facsimile with pronounced flaws”.

The issues tell the technical story:

• Any image above 8,192 pixels leaves the GPU compositor and falls back to the CPU, with a 6 GB memory peak, because that’s the egui-wgpu texture limit (issue 49, already closed, and the ones that came after it, 1015 and 4017).
• A 12 megapixel photo needs almost 800 MB just to open, adjust and export from the command line (issue 1637).
• Color management is rudimentary: a global working space only, instead of per document, and no view transform (issue 321). Eighteen issues mention CMYK, fifteen mention ICC profiles.
• Almost a hundred open issues mention PSD. Hue/Saturation layers composite differently from Photoshop, and saving over the file overwrites the original’s correct merged image (issue 4089).
• Fifty open issues mention “crash”.

The interface resembles Photoshop, so the screenshot is shareable, and whoever sees the screenshot assumes it’s a carbon copy. That’s expected in a two-week-old alpha. With interest, time and contributions, part of this gets fixed. And then the contributors will discover something the N64 projects never faced.

PhotoCraft today is that Ferrari replica built on top of a VW Beetle: the body has the right shape, you take a photo and most people say “wow, a Ferrari”. Then you turn the key and out comes the Beetle engine. If the photo got you hyped, that’s on you.

The target moves

Decompiling 1998’s Zelda is aiming at a stationary target. Nintendo isn’t going to release Ocarina of Time 2026 with a new file format. Copying a live product is another conversation, and we’ve seen this movie before.

In the 90s and 2000s the target was Microsoft Office. StarOffice became OpenOffice in 2000 and LibreOffice in 2010, and all of them spent years chasing a binary format, .doc, that changed from version to version and only got a public specification in 2008, when the game was already over. The proven part of that story is in the court cases: the European Commission fined Microsoft 497 million euros in 2004 for refusing to supply interoperability information, and 899 million in 2008 for failing to comply. .docx only became an ISO standard in 2008, in a vote so controversial that countries formally protested.

It took more than ten years. And when the format finally opened, Office no longer mattered the same way. The value moved elsewhere: today it’s 400 million paid Office 365 seats, 3 billion Google Workspace users and around 41 million Creative Cloud subscribers. Nobody wants to install that on a desktop, and so nobody has the binary.

Reverse engineering Google Docs means rewriting the product from scratch looking only at the interface, because the code that matters never leaves the server. After the world moved to SaaS, most proprietary software became a walled garden with no binary. No binary, nothing to disassemble.

You can build versions of it, of course. Immich replaces Google Photos for a person or a family: phone backup, face recognition, semantic search, all on your server. What it doesn’t replicate is the infrastructure and the training corpus that make Google’s search Google’s search. And Adobe made the same migration, in pieces.

Photoshop is far more than layers and crop

Here’s the part I know from having paid for it. The features that sell subscriptions today don’t even run on your computer.

Generative Fill and Generative Expand run on Firefly, in the cloud, and consume generative credits. Several Neural Filters, according to Adobe’s own documentation, need an internet connection because the processing happens on Adobe’s servers. AI object selection has had, since 2020, an option to process in the cloud for a refined result. All of this is code that doesn’t exist on your machine for anyone to disassemble.

Then comes what is in the binary, but took decades and partnerships to exist. Camera Raw carries lens correction profiles and per-camera color profiles for hundreds of models, built over twenty years and updated with every release. No clone guesses that. Either you have the data or you don’t.

And there’s color science. The example I always remember is GIMP and CMYK.

GIMP was born in 1995. The first native support for CMYK files arrived in 2022, and only for import and export, with pixels always in RGB. GIMP 3.0, from 2025, still has no CMYK editing mode. It’s on the roadmap as work in progress.

Thirty years of an open project, with good and motivated people, and the print shop still asks for Photoshop. That’s the size of the color science hole, and no coding agent invents color science: it reproduces what’s in the training data.

Why did it take so long, if it was the most requested feature? Because GIMP’s core was born with 8-bit-per-channel RGB baked into every layer, blend mode and filter. Supporting another color model meant rewriting the entire pixel engine, the migration to GEGL, which took the better part of a decade and was only finished in GIMP 2.10, in 2018. CMYK could only start after that.

And CMYK is a family of device profiles, with four inks, a per-printer ICC profile, ink limits and black generation rules, and editing in it means the whole pipeline has to compute in a subtractive four-channel model and round-trip through the profiles without drifting. A single developer, however good a programmer, without experience in this specific field will struggle to implement it, because the knowledge lives in print shops and color labs, and almost none of it is in a training corpus. In GIMP, the people who carried it forward were contributors who understand printing, and even then it took years. No new tool shortcuts that kind of knowledge.

And then there’s the layer that isn’t even technical: commercial licensing. Print-shop color is Pantone, and Pantone is a proprietary library. No open project can ship the palettes; the Inkscape developers reached that conclusion in 2005, and Linux.com explained the legal risk around the same time. Adobe itself felt it in 2022: when Pantone changed its business model, the libraries were pulled from Photoshop, Illustrator and InDesign, old files started opening with their Pantone colors replaced by black, and anyone who needs them pays for a separate plugin subscription. If even Adobe, paying, didn’t escape, imagine a clone that runs on goodwill.

Video is worse

In Premiere, After Effects and DaVinci Resolve, the problem multiplies. A cinema camera doesn’t deliver video, it delivers raw data on its own logarithmic curve: ARRI’s LogC4, RED’s IPP2. To turn that into an image you need the manufacturer’s transforms, and RED ships its own in an SDK that the editors integrate and update with every version. ACES, the industry’s neutral standard, depends on input transforms supplied by each manufacturer.

Blackmagic gives Resolve away for free and it decodes ARRIRAW and R3D. It does that because it pays for the SDK and the partnership on your behalf. An agent-built clone, “guessing” how the Alexa’s image should look, produces an image that doesn’t match the reference monitor, and in cinema that means it’s useless. That knowledge isn’t in any training corpus: it’s in contracts.

The Bun case: what it costs to rewrite big software

For a sense of the order of magnitude, the best public data point there is comes from Bun. In May 2026, Jarred Sumner rewrote the entire runtime from Zig to Rust using agents, and in July published the numbers:

• 535K lines of Zig in 1,448 files became a one-million-line Rust diff, in 11 days.
• Up to 64 Claude instances in parallel, 24 hours a day, every line reviewed by two adversarial agents and a fixer.
• 5.9 billion uncached input tokens, 690 million output tokens, 72 billion cache reads: around US$ 165K at API prices.
• 16K compiler errors fixed by 64 agents before CI went green on six platforms.
• The existing test suite, with more than a million assertions, passed 100% before the merge.

Read again what made it possible:

• the project’s original author at the controls
• a complete, working source code as reference
• a test suite with a million assertions serving as the oracle
• unlimited budget, because Bun has belonged to Anthropic since December 2025, and a pre-release version of Claude Fable 5

Sumner estimates three engineers with full context would have needed a year.

Now take each of those advantages away. PhotoCraft doesn’t have the Photoshop source to port, it has to invent. It doesn’t have a test suite that says “this matches Photoshop”. It doesn’t have Photoshop’s author.

And Photoshop is a 36-year-old product whose disk requirements Adobe lists between 10 and 100 GB, against a JavaScript runtime. Even without knowing the size of Adobe’s codebase, we’re talking about a bigger target, with no reference, no oracle and no owner. Orders of magnitude above US$ 165K, and even then it would be an approximation.

Why retro moves so fast

If it’s so hard, why does an old game port ship every day? Because retro stacks up every advantage the rest doesn’t have.

The binary is available and tiny. Super Mario Bros. on the NES: 40 KB. Super Mario 64: 8 MB. Ocarina of Time and Majora’s Mask: 32 MB each. A whole PS1 CD: 650 MB.

Compare with Baldur’s Gate 3, 150 GB, or with the latest Call of Duty, above 100 GB. That’s three or four orders of magnitude, and the scope shrinks along with it: a 1996 game has a handful of systems, not a physics engine with networking, a store and anticheat.

The technology is old and documented. Twenty-five years of community have already mapped the N64, PS1 and SNES hardware instruction by instruction. The agent discovers nothing; it speeds up work that already has a map. It’s the same pattern I saw in my retrocomputing projects: where there’s a reference and an oracle, AI flies; where there isn’t, it spins in brute force.

The target doesn’t move. Nobody is going to update 1998’s Zelda.

And the legal side was settled thirty years ago. Sega v. Accolade and Sony v. Connectix drew the outline. The ports require you to supply your own ROM.

A modern console is a PC

The second half of the explosion, the PS4, PS5, Xbox One and Switch ports, has another explanation: those consoles are PCs or phones in a different case. The PS4 uses an AMD Jaguar x86-64, the PS5 a Zen 2, the Xbox Series another Zen 2, the Switch an NVIDIA Tegra X1 ARM chip. Your PC’s processor runs that code natively. So nobody needs to emulate the CPU.

The remaining work is translating the operating system and the GPU. shadPS4 reimplements the PS4’s system libraries and recompiles the shaders: games ship from the factory with AMD GPU machine code, which the emulator decodes instruction by instruction and converts to SPIR-V, Vulkan’s format.

Azimuth, which makes Forza Horizon 2 run on Windows, translates Xbox WinRT calls to Win32 and DirectX 11.X to desktop DirectX 12, with the game’s x86 code running directly. AnyPS5 relinks the executable: it takes the PS5 binary and produces a native Linux or Windows binary, linked against reimplemented system libraries. In all three cases, Proton, DXVK, VKD3D and MoltenVK had solved the graphics translation layer years earlier.

The reverse proof is the consoles that weren’t PCs. The PS3 uses the Cell, a PowerPC with seven active coprocessors (the SPEs), each with its own local memory and no cache, and RPCS3 has been at it since 2011, with SPU emulation still the bottleneck today. The Xbox 360 is PowerPC too, which is why Sonic Unleashed needed XenonRecomp to translate PowerPC into C++. Reverse engineering is case by case, and the architecture decides whether the case is easy.

AI is in the loop, and there’s already a fight

That the 2026 ports use AI, many of them say outright. The Silent Hill decomp writes in its README that development is “heavily AI-assisted (Claude Opus 4.6, 4.7 and the newer Fable model), and we’re open about that. It is not automated translation of the game”. The Pokémon Stadium recomp lists Claude as a contributor.

The devs of the Zelda and Banjo recomps, who spent years doing this by hand, went to war with what they call “slopcomps”, agent-generated ports of alpha quality.

And it’s worth separating headline from actual state here too. AnyPS5 has a 0.1 version from September that, according to those who tested it, runs one 2D indie game; the viral claim that “the PS5 is 80% ported to PC” comes from fans, and no 3D game runs. Astro Bot runs, but in emulators (KytyPS5, SharpEmu), which take the traditional path. Forza Horizon 2 runs, and Azimuth is a closed binary from a studio that declares itself “AI assisted” without saying anything more.

“But in two years tokens will cost nothing”

The standard answer to all of this is: it’s hard today, in two years it’s trivial, because AI grows exponentially. The numbers say otherwise.

The price of the most expensive tier barely fell. GPT-4 in March 2023 cost US$ 30 and 60 per million input and output tokens; Claude 3 Opus in 2024, 15 and 75; today’s frontier models, Fable 5.1 and GPT-6 Astra, cost 10 and 50. In three and a half years, the frontier got between 1.2 and 3 times cheaper, depending on which end you look at.

What really fell was the cost of a fixed quality: Epoch AI measured drops of 9 to 900 times per year depending on the task, and in a 2026 review sums it up as “very roughly 5 to 10 times per year”, with the caveat that it might slow down. That’s real and it’s great.

But apply the math to Bun. US$ 165K divided by 10 is US$ 16K. By 100, US$ 1,650. That’s to port a runtime with the source, the tests and the author in hand.

For an amateur trying to clone Photoshop with none of that, the bill starts orders of magnitude higher and falls in the same proportion. Cheap isn’t the same as trivial.

And the “exponential” premise died in 2024. Ilya Sutskever said at NeurIPS that pre-training as we know it will end, because there’s only one internet. Epoch projects that reasoning model scaling converges to the general frontier rate in about a year.

I’ve written about this three times in recent weeks: the limits of what the model reproduces, the convergence of raw models with the gains coming from the harness, and the languages benchmark where the frontier models tied at the ceiling. The tool we have is the tool we’ll have for a good while, with incremental improvement. Plan with it.

Worth recalling the number that opens the limits post: per the Octoverse 2025, GitHub’s official report, 81.5% of contributions on the platform happened in private repositories. That’s the code that really matters, the code that pays salaries, and no LLM has seen a line of it. The model reproduces what was in the training data, and that code was never there.

Now extend that to every SaaS product and every component it uses. The Adobe code that’s actually worth something, the color engine, the profiles, the cloud filters, isn’t available anywhere, not even as a binary. Anyone who wants to reproduce it will have to redo the research and development, expensive and slow, over the same years Adobe took. And at the end they still run into third-party licensed intellectual property, Pantone, camera SDKs, manufacturer profiles, that you will never be able to have.

Answering the list from the top

Does PhotoCraft exist? It does, it’s a two-week-old alpha with more than 800 open issues, rudimentary color management, freezing above 8K and opening PSDs wrong. It looks like Photoshop in a screenshot. It can improve a lot, and it will discover that the target moves and that Photoshop’s expensive parts live in the cloud or in manufacturer contracts.

Does REA exist? It does, it’s good, and it’s a toolbox for people who already know how to use Ghidra, requiring the binary in hand, the tools installed and hundreds of thousands of tokens per analysis. The project itself avoids saying it clones programs.

Did recomps and decomps accelerate? Yes, for real, and AI has a part in it. They accelerated where the binary exists, is small, has been documented for 25 years and doesn’t move. Or where the console is a PC in disguise and the work is API translation, solved by Wine and Vulkan years earlier.

Is Adobe dead? Adobe has around 40 million subscribers by the most cited estimate, the features that sell subscriptions run on its servers, and thirty years of GIMP still leave the print shop asking for Photoshop. I wish it were otherwise. The data says what will happen is what always happened with clones of a live product: years of chasing, and when you catch up, the value has already moved.

Are programmers dead? Rewriting Bun required Bun’s author. The decomps that work have people who know the hardware driving the agent, and the ones that don’t became “slopcomps”, name and all. Reverse engineering got cheaper and more accessible, as it did with Ghidra in 2019, and it’s still an engineer’s job. Without us, the tool returns a pretty screenshot.

Proprietary software with a binary in hand will come under pressure, and it should. Most of the software you use has no binary at all, and the software that does already depends on cloud services that don’t disassemble. Software engineering with AI has a great road ahead. “It’s over” headlines get clicks and don’t compile.

This is my thesis, and I know it’s unpopular. It took me ten years of patience to be able to write this piece. I stayed quiet watching this theater repeat itself year after year, waiting for the right moment to document everything I witnessed up close, and today I get to watch, with real pleasure, my own predictions come true one by one.

And before some smart aleck tries this one: I know boycotts, doxxing, and witch hunts exist with no CODE_OF_CONDUCT.md whatsoever, they always have. The title takes aim at what this file turned into: the instrument that took an internet-mob tactic and stamped it as official project policy, with a committee, a process, and a veneer of institutional legitimacy. A 500-line markdown file scares nobody by itself; what it became does.

Easy money was the fuel. The code of conduct was the weapon these people built to formalize what used to be just a shout in the street.

One question is where the energy came from; another is the instrument it adopted to turn into permanent power inside the project. Keep that distinction in mind, because it holds up the whole piece. But before getting to the philosophy, let me tell the economic part, because without understanding the money you won’t understand the rest.

The bubble that funded all of this

From roughly 2012 to 2022, the tech industry lived through the biggest hiring bubble in history. Zero interest rates, infinite capital, and big tech companies growing like there was no tomorrow. We reached the surreal point of companies hiring engineers with no work for them to do. Keith Rabois, of the PayPal mafia, publicly accused Google and Meta of hiring thousands of people to do “fake work”, out of vanity, and so they wouldn’t go work for competitors. A former Meta employee, laid off in the first 2022 wave, put it better: “they were hoarding us like Pokémon cards”. The “rest and vest” culture, collecting salary and stock options while doing almost nothing, had already been documented back in 2017.

It was this bubble that funded the “coding is the profession of the future” wave. Bootcamps went from 2,178 graduates in 2013 to nearly 25,000 in 2020 in the US and Canada alone, growth of more than a thousand percent. Bloomberg resolved to learn to code as a New Year’s resolution in 2012. Obama wrote a line of code on TV in 2014.

I told this story in more detail in a February 2020 video, back when the bubble was still inflating (transcript here):

Tech influencer became a profession. Everyone was going to be a programmer.

Then the bubble popped. 2022: nearly 165,000 laid off. 2023: more than 262,000, according to Layoffs.fyi. Meta cut 11,000 in November 2022 with Zuckerberg admitting “I got this wrong”, and another 10,000 in the “year of efficiency” in 2023. Amazon cut 27,000. Google, 12,000, with Pichai admitting that “we hired for a different economic reality than the one we face today”. Stripe was the most honest: “we overhired”.

I recorded that burst in the heat of the moment, in a November 2022 video (transcript here):

And because the timing writes its own joke, on November 30, 2022, right in the middle of the bloodbath, ChatGPT came out. A hundred million users in two months, the fastest-growing app ever seen up to that point, according to a UBS estimate. The headlines turned into an ACM talk called “Large Language Models and the End of Programming”, Jensen Huang saying no child needs to learn to code anymore, Devin announcing itself as the first AI software engineer, Dario Amodei promising AI would write 90% of code within three to six months. Spoiler: it didn’t.

Why does this story matter? Because it was exactly during this decade of easy money that open source got colonized. When there’s money to spare and a shortage of real work, there’s time and people to spare for playing politics inside projects. And that’s what happened.

The decade of the witch hunt

The central artifact of this story is the Contributor Covenant, created in 2014 by Coraline Ada Ehmke and adopted by thousands of projects, including practically every giant in the industry: CNCF, Apple, Google, Microsoft, Linux. The author herself, on the day Linux adopted her code, tweeted in no uncertain terms: “Some people are saying that the Contributor Covenant is a political document, and they’re right”. When the document’s own author admits it’s political, the debate over “safe space” is over before it starts.

The list of victims from this era is long, so let’s get to the main ones.

First, it’s worth noting how far this crowd’s reach went. Coraline worked at GitHub between 2016 and 2017, until she was let go (her version of events is in the piece “Antisocial Coding: My Year at GitHub”). And GitHub was the perfect target: it’s where practically all the world’s open source lived. It was in this era that the original founders left the picture. Tom Preston-Werner resigned in 2014 amid the Julie Ann Horvath harassment scandal, even though the internal investigation concluded there was nothing illegal, only “errors in judgment.” Chris Wanstrath had already announced he’d step down as CEO in 2017 and, after the sale to Microsoft in 2018, stayed on a few more years as a technical fellow before leaving for good. Today none of the original founders work there.

Her legacy outlived the firing. The Contributor Covenant became one of the templates GitHub makes easy to adopt when you create a repository’s CODE_OF_CONDUCT.md. And in 2020 came the crown jewel: in the middle of the George Floyd protests, GitHub announced it was retiring the name master, and since October 1, 2020 every new repository is born main.

The debate was stupid from the start. Git never had a slave branch. Petr Baudis, who named it in the original scripts, explained on X that master there came from “master copy”, like the master recording of an album (Baudis himself later said he now prefers main; the etymology hasn’t changed). Not even that detail held back the change: even the Software Freedom Conservancy publicly endorsed the switch, and anyone with automation assuming master had to scramble to catch up. Nobody got any more protected because of this change, but it’s there, in every programmer’s workflow, every single day.

Brendan Eich, 2014. The guy invented JavaScript, co-founded Mozilla, was CTO since 2005. He became CEO and lasted eleven days in the job. The crime: a thousand-dollar donation in 2008 to California’s Proposition 8. Employees tweeted calling for his head, OkCupid blocked Firefox users with a protest message, and he fell. Andrew Sullivan, gay and one of the first prominent advocates for same-sex marriage, wrote at the time “The Hounding of a Heretic”: when careers depend on an ideological purity test, the witch hunt has already won. And notice: there was no code of conduct involved here at all, it was pure boycott pressure. The method already existed before the document; the document only made it official.

Larry Garfield, 2017. Twelve years contributing to Drupal. When it leaked that he took part in a BDSM subculture, on a private site, outside the project, Drupal’s conduct committee investigated and concluded: no code of conduct violation. Dries Buytaert went over the committee’s own head and expelled him anyway, because “association with his belief system” was incompatible with the project’s goals. TechCrunch summed it up the same way: punished for something said outside the project. Eighty-five developers signed an open letter threatening to leave. It didn’t help. And notice the detail that buries the “safe space” thesis: the code of conduct process worked and cleared the guy. When the mob pushed, the paper held nothing; the person at the top decided, like it always was.

Node.js, 2017. The 13-person TSC voted on expelling Rod Vagg for, among other things, having tweeted an article questioning the side effects of codes of conduct. Reading criticism of a code of conduct almost became a code of conduct violation: the vote was 6 to 4 against expulsion, by a narrow margin. The machine lost that round, but the message had already gotten out: four of the people who wanted Vagg’s head resigned from the committee that same day, and the project got a fork called Ayo.js hours later. Losing the vote didn’t stop the damage.

Linus Torvalds, 2018. In September, according to reporting at the time, the New Yorker had sent him questions about his abusive behavior in emails. That same weekend, Linus apologized and announced he’d take some time off to “understand people’s emotions” and the kernel swapped the Code of Conflict for the Contributor Covenant. Linus has been blunt in emails forever, everyone knows that, and he came back a month later. But the message was sent: if not even the guy who created the kernel was safe, nobody was.

Richard Stallman, 2019. The creator of the GPL, founder of the FSF, the embodiment of free software. An MIT mailing list thread leaked in which he discussed the legal semantics of the Minsky/Epstein case. Vice ran headlines saying he had “defended Epstein” and called the victims “entirely willing”, a reading the email thread itself doesn’t support: he was questioning the legal terminology of the accusation against Minsky. The “Remove Richard Stallman” campaign exploded, and within days he resigned from MIT and the FSF presidency. When he returned to the FSF board in 2021, an open letter with more than 3,000 signatures and dozens of organizations came out demanding his head and the whole board’s. Red Hat cut funding to the FSF. A support letter gathered nearly 7,000 signatures and, delicious detail, Debian voted on a resolution about the case and the winning option was to say nothing. Even faking neutrality took a vote.

And there’s the most recent case, and maybe the most instructive one: Tim Peters, 2024. A Python legend, three decades of contribution, suspended for three months by the PSF’s conduct committee over vague accusations of creating an “atmosphere of FUD”, in a fight over the foundation’s bylaws and the committee’s own methods. The community reacted badly, but there was no reversing it: he served the three months and only came back once the suspension expired, in November. The pattern held: disagreeing with moderation became a punishable offense.

DHH, 2021. I saved this one for last because it’s the case that changes the story. And note: this wasn’t even open source, it was his own company. The same mechanism, now inside the office. In April 2021, at the height of the BLM era, an internal DEI committee inside Basecamp, the company of Ruby on Rails’ creator and Jason Fried, dug up an old “funny customer names” list that had been circulating internally. The discussion escalated until an employee invoked the “pyramid of hate” and argued that list was the foundation of racial violence and even genocide. The founders’ response was to shut down the topic, dissolve the committee, and ban political and societal discussion on internal channels. The internet exploded. At the next all-hands, there were two and a half hours of people crying and yelling on Zoom. Ryan Singer, eighteen years at the company, said there that he didn’t accept the “white supremacy culture” label being applied to the company. He was suspended half an hour after the meeting and resigned that weekend. In the end, a third of the company, twenty of the 57 employees, left with a voluntary severance package.

And this is where this case splits off from all the others: he didn’t bend. No public humiliation ritual, no apology, no walking it back. He preferred to lose a third of the company over handing over control of it. Basecamp survived, went back to being 37signals, and DHH learned right there, firsthand, what kind of people he was dealing with. Hold on to that name, because it comes back.

Someone’s going to point out that his rule is also a written document banning a topic. Yes, and the difference is exactly the point: DHH’s rule bans an entire subject, the same for everyone, no matter which side. A code of conduct bans a person and an opinion, selectively, depending on who’s in power that month.

One locks the topic at the door. The other opens a courtroom inside.

Notice the pattern. In none of these cases was the problem code. In none of them did anyone commit a bug, steal code, sabotage a release. The offenses were opinions, political donations, private life, semantics on a mailing list. The technical criterion got replaced by a political one, and the code of conduct was the legal instrument of that swap. These are famous cases, not statistics. But when the list includes the creators of JavaScript, the GPL, and Linux, the sample doesn’t need to be big to make the point.

And the results?

Ten years of the code-of-conduct era should have left behind a trail of good numbers. If the justification was protecting minorities and making open source more diverse and less toxic, where’s the improvement? I went looking for the serious research on the subject. What exists tells an interesting story.

On adoption: Tourani, Adams, and Serebrenik measured in 2017 that around 35% of GitHub’s 150 most popular projects had a code of conduct. And that enforcement was rare: the creators of these codes, in a sample of four interviewees, talked about single-digit case counts over years. A 2021 CSCW study looked at 52,000 repositories: 12.6% had a CoC, and only 10% of the conversations mentioning the code were real moderation use of it. Most adoptions happened with no visible public discussion in the repo. The same paper states, in plain words, that there is no empirical evidence that a code of conduct attracts new contributors.

On attracting people, by the way, Qiu et al. measured what actually makes someone join a project: a good README, star count, recent activity, an issue template. A code of conduct didn’t even make it in as a variable in their model, and note that they did test maintainer responsiveness, which also came back not significant. The study that specifically measured where a CoC ranks among the factors was a separate one, Fronchetti, Wiese, Pinto, and Steinmacher, also from 2019: a CoC ranked among the worst-placed factors for attracting new contributors. Nobody picks a project because of its code of conduct.

On diversity, which was the original promise, there is a specific study, and the answer is no. Robson, at ESEC/FSE 2018, looked at GitHub’s 500 most popular projects: projects that adopted a CoC saw women’s participation grow at practically the same rate as those that didn’t (roughly a 1.44% increase versus 1.43%, per the later survey that cites the study). No statistical difference to back up the promise. Enache, in a 2017 master’s thesis for TU Eindhoven, covering 149 open source communities, reached the same conclusion: no significant result showing a CoC changes women’s participation.

And there’s a new, heavyweight piece of research, published now in 2026 at ICSE, the field’s most important conference: Sun et al. ran a genuine causal experiment, comparing 4,684 pairs of repositories that adopted a CoC against matched pairs that didn’t. The result cuts both ways. Adopting a CoC does attract more new contributors, and that effect grows over time. Except adopting a CoC also increases the number of existing contributors who disengage, an effect concentrated specifically in the first one to three months after adoption. In other words: the most recent and most rigorous study that exists shows, with numbers, the exact pattern this piece has been documenting case by case the whole time. Adopting the document doesn’t build a new community, it pushes out the people who were already there.

GitHub’s 2017 survey already showed 95% men and 3% women in open source. The best long-term data that exists, from Rossi and Zacchiroli at ICSE 2022, analyzed 2.2 billion commits from the Software Heritage archive. Gender was detectable for 64% of authors, and within that group, women are 13.5% of authors and sign 8.1% of commits. Their participation had been growing slowly and steadily for twelve years, and dropped during the pandemic. The paper doesn’t discuss codes of conduct, so what follows is my own reading, not the study’s: a curve that climbs the same way the whole decade, with no visible step up when the Contributor Covenant spread, is the opposite of evidence that the document made a difference.

On toxicity, the ICSE 2022 study finds, in a footnote and by extrapolation, something close to 1.3 toxic comments per thousand on GitHub. Nobody has a historical series comparing before and after the CoC era. There simply is no baseline to say whether things got worse or better.

The only randomized experiment that would actually support the case for rules is Matias’s, published in PNAS in 2019: rule reminders actively displayed on a randomly-sampled set of r/science threads increased newcomer participation by 70%. Except the experiment is on Reddit, with the rule pinned right in front of whoever walked into that specific thread. A static file forgotten in a repository, that nobody reads after adoption day, doesn’t come close to that. The very research that shows a rule working is proof that the problem was never whether the file exists or not. It’s that nobody enforces it, nobody displays it, nobody makes it stick.

To sum up: a whole decade of codes of conduct, and the original promise remains exactly that, a promise. What got documented was adoption without discussion, rare enforcement, and, at best, a whole lot of political process.

As protection, it’s almost never invoked. As a political weapon, it only needs to be invoked once, against the right person.

The pushback came from where nobody expected

Easy money ran out in 2022, and with it, the industry’s patience for this theater. And leading the pushback was the guy who had already refused to bend back in 2021: DHH, an old-guard ex-Mac fanboy.

DHH has been writing against this wave for a while now: “The waning days of DEI’s dominance” in 2022, “DEI is done” in 2024. In 2022 Ruby Central pulled him from the RailsConf keynote, the conference for the framework he himself created, saying it wanted to “share the opening stage with other contributors”. The following year Rails World was born, the official Rails Foundation conference, and DHH became its keynote speaker. In 2024 he launched Omakub, and in June 2025, Omarchy: Arch Linux with Hyprland and a bunch of opinionated scripts on top, which had passed 40,000 stars on GitHub by September 2026 and became 37signals’ default environment for anyone touching infra and Ruby.

Then the cancel machine switched on again. In September 2025 he published “As I remember London”, and the reaction was the usual script: a petition to remove him, accusations, an attempted boycott. His response was “We’ve all had enough of this nonsense”: “every few years, the same sad little clique of Ruby malcontents tries to cancel me from Rails”.

A month later, in October 2025, it was Framework’s turn, the laptop maker: a thread with more than 1,500 replies on the company’s own forum, opened by a Debian developer calling the Hyprland community, which Framework sponsored, “toxic and hateful,” and threatening a boycott because the company also promoted Omarchy on social media. The Framework CEO’s response is the line this whole decade had been missing:

“We deliberately created a big tent, because we want open source to win. We don’t partner based on the beliefs of individuals or organizations.”

And the machine didn’t just come after him. Ruby Central, the same organization that had disinvited DHH from the keynote in 2022, gave him a stage at RailsConf 2025. The retaliation came in money: according to developer Joel Drapper’s reporting, Sidekiq pulled its $250,000-a-year sponsorship because of it. Weeks later, in September 2025, Ruby Central stripped GitHub access from every longtime RubyGems and Bundler maintainer, citing supply-chain security. Ellen Dash, who had maintained the project for ten years, quit, calling the move a “hostile takeover,” and Drapper’s investigation points to pressure from Shopify, which had become practically the organization’s only source of money. Ruby Central itself ended up publishing an incident report in April 2026, promising to “strengthen governance.” That’s the whole pattern: when the machine can’t take the target down, it burns the house down around them.

A GNOME developer published a piece attacking Omarchy on GNOME’s official blogs site. And the result of all that fury? Nothing. In August 2026 the Omacom Foundation was born, with eight million dollars at launch: a million each from Tobi Lütke (Shopify), Patrick Collison (Stripe), Michael Dell, Jack Dorsey, Matthew Prince (Cloudflare), Brendan Iribe, Jason Fried, and DHH himself. The foundation became Hyprland’s exclusive sponsor, with Vaxry working on it full-time. When 1Password came in as a sponsor, the cancellation attempt was immediate, and so was the CEO’s internal response: “our donation is not an endorsement of personal opinions”. And the game goes on.

And I put my money where my mouth is: I made my donation to the foundation precisely because of the patrol’s whining. Nothing irritates that crowd more than watching a cancellation fail in real time.

This is the point: the machine still exists, but it lost its power. In 2014 it brought down a CEO in eleven days. In 2026 it can’t even scratch the sponsorship of a niche distro. The documents are still there, in GitHub’s template; what ended was the firepower of whoever wielded them. What changed was the money, and yes, the pushback is also money: eight million dollars from eight rich men.

And before someone points out that money doesn’t prove merit: it depends. A millionaire made by government cronyism, fraud, or favors has no merit at all. But most millionaires made their money by producing, and that’s the case for Omacom’s eight patrons. Money earned by producing is the measure of the merit of whoever earned it, as I already wrote here back in 2011, about Francisco d’Anconia’s money speech in “Atlas Shrugged”.

Judge by the result the donation bought, not by the declared intent of whoever signed the check.

The 49.5 billion corporate dollars from 2020 didn’t produce a single extra gram of measurable diversity, the numbers up above prove that. Eight million dollars from individual patrons produced a full-time maintainer writing actual code. The bubble that funded armies of people with no real work popped, and whoever was left was whoever was there for the code.

The philosophical part

Let’s get to the official excuse: codes of conduct exist to “protect minorities.” On the surface, who would be against protecting minorities? Not me. The problem is that the phrase is vague by design.

What is a minority? I already translated the chapter “Man’s Rights” from Ayn Rand’s “The Virtue of Selfishness” here on the blog. The line that interests me here is from another chapter of the same book, “Racism,” and it remains unbeatable:

The smallest minority on earth is the individual. Those who deny individual rights cannot claim to be defenders of minorities.

And that’s exactly what these codes do in practice: in the name of an abstract, collective minority, the concrete individual gets hunted down. Doxxing (exposing someone’s personal data), harassment campaigns, pressure on employers, bans. When the modus operandi for “protecting minorities” is coordinated bullying against one person until they buckle, you’re oppressing the smallest minority there is.

This topic, by the way, is an old one for me. In December 2018 I published the video “Anti-Parasite Manifesto: Be a Creator” on my channel. At the time I couldn’t be explicit, the thought police were still too strong. But whoever watched closely got the message. It was my breadcrumb for this story that I’m only now able to tell properly.

And there’s the second problem, a more fundamental one: open source is about software. The GPL, which this crowd looks down on so much, solves the one protection a software project can’t afford to lose: the code’s. It guarantees the code stays free, period. It doesn’t ask who wrote it, who they voted for, what they tweeted, what they donated to. The compiler doesn’t check for ideological purity. Open source has always been the most inclusive community that ever existed precisely because of this: the only passport was the diff. The code of conduct made open source less inclusive, because it added a new entry criterion: politics. And politics is a stupid criterion for software.

“But without a code of conduct, how do we deal with real harassment?” With the same tool as always: a maintainer’s common sense and, when necessary, the law. If someone directly attacks another person, sexual assault at an event, for example, banning them is common sense and never needed any document. Harassment, threats, and defamation are already crimes in practically every country, and crime gets settled through the law. What I can’t stomach is something else: going out and stalking someone’s online life to dig up a random opinion, with no relation to any crime, and demanding a ban over words with no criminal consequence. These committees were always great at punishing opinion and terrible at punishing crime, so the document was never about that.

And I’m not the only one saying this. Eric S. Raymond, the guy who wrote “The Cathedral and the Bazaar”, the 1997 essay that validated Netscape’s decision to open-source Mozilla and that pretty much wrote the rulebook for open source, co-founder of the OSI, editor of the Jargon File, author of fetchmail, went on X in September 2025 to declare the code-of-conduct era a complete failure. In his words: ten years of “drama and idiocy”, an “infectious social insanity” that produces politics, intrigue, and negative useful work. The recommendation is as direct as it gets: don’t adopt one; if you already did, delete it. And if some bureaucracy forces you to have one, the suggested replacement is a single sentence:

“If you are more annoying to work with than your contributions justify, you’ll be ejected.”

That’s what I said two paragraphs above: a maintainer’s common sense.

And the detail that closes the loop: ESR himself had been removed from two OSI mailing lists in 2020 over posts that “violated the code of conduct” of the organization he helped found.

The guy who wrote the rulebook, ejected by the document. That image sums up the whole era.

How we got here

It’s worth taking a step back and telling where all this came from, because open source was only one of the fronts. The starting shot, in my reading, was GamerGate, in 2014. In August of that year came the “Zoe Post”, the ex-boyfriend’s rant about developer Zoe Quinn. Twelve days later, and about 48 hours after the #GamerGate hashtag caught fire, about a dozen gaming sites published variations of the same article: “gamers are over,” gamers are dead, it’s finished.

Shortly after, the GameJournoPros leaked, a closed group where gaming journalists coordinated coverage. The public realized right away that gaming press had turned into an ideological club, and hit back with their own version of an organized boycott: the “Operation Disrespectful Nod” campaign flooded Intel with complaints until the company pulled its ads from Gamasutra (the press at the time called it an “anti-feminist campaign”; to me it’s just organized consumer pressure, the same instrument Sidekiq used against Ruby Central further down the line).

And it’s worth pinning down the principle here, because it applies to both sides for the rest of this piece: organized consumer pressure is fair play, no matter which side it comes from. The problem was never pressure. It’s doxxing, threatening someone’s job, and a committee faking neutrality to impose the result it already wanted before opening the process.

For years, from 2021 to June 2025, Wikipedia’s article on the subject lived under the title “Gamergate (harassment campaign)”, treating any criticism of the journalism as a pretext for harassment. The title got switched back to plain “Gamergate” once the most hysterical phase had passed, which should be read as a confession, not as if the case were closed: they renamed it back once defending the political label got too costly, the exact same pattern of quiet retreat that shows up throughout this whole story. While it lasted, it lasted for precisely the decade in which that mob had the firepower to make it stick.

The editorial fight got so ugly that Wikipedia’s arbitration committee sanctioned more than a dozen editors, on both sides. And note that I don’t even need to accuse Wikipedia on my own: Larry Sanger, co-founder of Wikipedia, wrote the piece “Wikipedia Is Badly Biased” in 2020, declaring the project’s neutrality dead, and in September 2025 published “Nine Theses on Wikipedia”, calling for reforms like ending source blacklists and ending permanent editor bans. When the founder says the house has been taken over, believe the founder.

The gamers’ side of this story is in the book “SJWs Always Lie”, by Vox Day, from 2015. I already know what’s coming: “Vox Day” and “Milo Yiannopoulos” are names that make people scream just hearing them, and GameJournoPros, by the way, was also originally broken by that same Milo. I don’t care about the reputation of whoever’s telling a story, I care whether the story is true. A partisan source from inside the fight, fair warning, but the central fact matches what Wikipedia itself and the press at the time document with zero connection to either of those two names: the GameJournoPros list really did exist, a closed group of about 150 people in games journalism swapping notes on how to cover the case.

The chapter “Counterattack” tells GamerGate from the inside, and the book’s thesis sums up the decade: these people always lie, always double down, always project onto others exactly what they themselves do.

From GamerGate onward, it was dominoes. Anita Sarkeesian turned her Kickstarter from a $6,000 goal into $158,000, became a global authority, went to speak at the UN in 2015 about “cyber violence,” and games journalism never recovered. Her Feminist Frequency shut down in 2023, but the logic she kicked off migrated inside the studios: the “inclusive narrative” consulting industry was born, with Sweet Baby Inc leading the way.

Sweet Baby’s CEO, Kim Belair, was recorded at a 2019 GDC talk, a public recording that circulates independently of the site that first surfaced it, advising anyone seeking internal approval for “representation” consulting to “go grab coffee with the marketing team and terrify them” with the possibility of what would happen if they didn’t get what they wanted. In 2024, a Brazilian created a Steam curator page (Valve’s own feature where any account can publish game recommendations and gain followers) named “Sweet Baby Inc Detected.” One employee at the company individually tried to bring the profile down on their own, and Valve also acted through its own moderation; even so, the result was the group exploding to more than 350,000 followers.

And then came the flops. Suicide Squad: Kill the Justice League, with confirmed Sweet Baby consulting, cost Warner 200 million dollars in losses. Unknown 9, from the studio where Sweet Baby’s founding duo used to work, laid off staff en masse a month after launch.

Then came 2020. With BLM, the same playbook became state policy: the 50 biggest American companies pledged 49.5 billion dollars in “racial justice” measures, DEI job postings grew 123% within months, Biden signed an “equity” executive order for the entire federal government on day one of his term, and the European Union rolled out its 2020-2025 anti-racism plan. It was the peak: the patrol had reached the US presidency and the EU’s leadership.

The retreat came as fast as the rise. The US Supreme Court struck down affirmative action in June 2023, companies laid off thousands of DEI professionals, Walmart, Meta, McDonald’s, and Amazon dropped their programs, and in January 2025 Trump revoked the equity orders on day one.

I told all of this just to give context: what happened in open source wasn’t an isolated phenomenon. It was the same script, with the same methods, across every culture and tech industry at the same time. The difference is that in open source, the resistance took longer to organize. But it organized.

My Cortlandt

It was this pressure that pushed me out of organizing RubyConf Brazil. I founded the event in 2008, back when it was still called Rails Summit, and in the last edition I organized, in 2016, we drew 1,500 people. When I announced my departure, I wrote that there was no drama involved. That wasn’t the whole truth: the patrol had already reached tech conferences, and I refused to turn the event I created into one more stage for it.

Let me give a small example of what it means to be pressured into forcing diversity. As the data I showed above indicates, women are somewhere between 3% and a bit over 13% of open source contributors, depending on how you measure it: self-reported survey or name-based detection in commits. My channel’s analytics show the same range, 3 to 5% at most, and that proportion hasn’t changed in ten years. Every year I opened a public Call for Papers: anyone could submit a talk. And my selection process was always blind: I read every submission without knowing who had sent it, on purpose, so the choice would be based on the merit of the topic and never on the person.

In the patrol years, the pressure was never direct with me. It was that diffuse, external pressure that every event had to be “more diverse.” And in practice that could only mean one thing: a new phase in the process. After the blind selection, reveal who submitted what, to check whether the lineup was “diverse enough.” Except that’s a mathematical impossibility. Submissions kept following the same 3 to 5%. Even approving every woman who submitted, the imaginary quota didn’t add up. The way around it was to go out and invite people directly, choosing by profile instead of by topic.

And the practical result of that scheme, wherever it’s applied, is cutting people who got in on merit to open a spot for people chosen by an irrelevant external policy. That drags the event’s quality down instead of up. And notice: this isn’t an argument against any woman. It’s the opposite. The moment the quota enters the process, the doubt stops being about one specific speaker and starts hanging over everyone who steps on stage. It doesn’t matter who’s talking: if someone in the audience disagrees with the content, there’s always the leftover question, “did Akita pick this one for the quota?” From then on, every speaker carries a suspicion they don’t deserve, and everyone’s merit gets devalued along with it. It hurts the minority the policy claimed to protect, it hurts the other speakers, it hurts the audience. It’s lose-lose all around.

And there’s a part of this story nobody sees from outside. Some of the people invited that way turned it down on the spot, “because the event wasn’t diverse enough.” The refusal made the event even less diverse, obviously. And afterward they’d go on social media to trash the event, as if I’d never invited anyone. That’s the level of garbage I had to swallow every year.

And let this be very clear: there’s nothing I want more than to see more women in tech. What I can’t convince myself of is that forcing a quota, the way I described above, helps with that. Everything I saw in practice points the other way: it hurts more than it helps. And if I don’t believe it’s beneficial, I’d rather not do it.

Want a recent example of a woman I admire in the industry? Asha Sharma, who took over as Xbox CEO in February. Since then it’s been one result after another: she cut Copilot from the consoles and restructured the division to focus on what matters, sold studios and cut costs without cancelling a single announced game, and this week brought Kojima Productions to Xbox to publish Hideo Kojima’s next game, after PlayStation cancelled the project in mid-2026. Notice the discourse around her: zero mention of “gender,” zero agenda.

Just numbers: cut unnecessary costs, bet on the right calls, improve value for the customer. That’s merit. You don’t need DEI for that.

Until I decided enough was enough. Anyone who’s read “The Fountainhead” knows what I did: like Howard Roark, the architect who blows up his own building when they tamper with his design, I dynamited my Cortlandt. More precisely: the event as it existed while it was mine. The brand survived a few more years in other hands, without the same soul, until it disappeared. And I had already signaled this philosophy here on the blog back in 2011. An individual does nothing for others: he does it for himself. If what you build benefits other people as a side effect, great, but that was never the reason. When the parasites try to take what you built, you blow it all up yourself. Because you can. Whoever built it once builds it again from scratch.

That’s what I did. I traded the conference for my YouTube channel, which didn’t depend on a sponsor, a committee, or anyone besides me. And the channel grew way beyond anything the conference would ever have become. Then I sat back and waited for the bubble to pop, because I knew it would pop: I wrote it here on the blog and repeated it in videos years before it happened. It popped. Patience always wins.

Conclusion

Ten years of codes of conduct, and here’s the scoreboard: zero evidence it increased diversity, no toxicity baseline to compare before and after, and the most recent and most rigorous causal study that exists shows the document pushing out old contributors more than it builds new community. The promise was to protect minorities. The delivery was a collection of heads: the creator of JavaScript, the creator of the GPL, the creator of Linux, all put through the public humiliation ritual. None of it over code. All of it over opinion.

And notice how this era ended.

The machine didn’t lose the argument, it lost its funding.

It was only once easy money ran out that the armies of people with no real work evaporated, and whoever was left was whoever was there for the code. Meanwhile, the builders kept building: Brendan Eich got pushed out of Mozilla in 2014 and founded Brave the following year, today with more than 100 million monthly active users and a valuation near a billion dollars. DHH lost the keynote and created a bigger conference, lost a third of the company and helped raise an eight-million-dollar foundation. I left my conference and grew far more on my channel. A parasite can take an institution. It can’t take the ability to build. Whoever built it once builds it again from scratch.

Open source recruits volunteers who want to contribute code. Any discussion that doesn’t involve code is a distraction at best and sabotage at worst. And the answer to “what do we put in place of the code of conduct” fits in a single sentence, one the ESR already wrote: if you’re more trouble to work with than your contributions justify, you’re ejected. That’s always been how it worked. The only passport is the diff.

The rest is politicking. And politicking, to use the precise technical term, is bullshit.

And here’s the final practical recommendation. If your open source project has a CODE_OF_CONDUCT.md, delete the file. If your main branch turned into main in the 2020 wave, rename it back to master. Partly out of spite, I admit. But mostly to exercise the freedom you just got back to do this without being cancelled for it. Freedom you don’t exercise atrophies. No clarifying note, no committee vote, no asking anyone’s permission. Just because you can again.

Back in July I published What’s New in My AI-MEMORY, where I showed off ai-memory run: switching from Claude Code to Codex without losing your line of work. That day we were on version 1.17.1.

Today 2.0 shipped. And this time I’m not going to rehash how the hooks work or how a session turns into a wiki page. That’s already in the earlier posts. Here I want to talk about where ai-memory landed against the competition, what 2.0 brings, and why it earned the jump to a “2”.

If you’ve never heard of the project, the summary is short. ai-memory is a long-term memory server for your coding agents. It captures what happened in the session, consolidates it into Markdown pages, and hands the right context to the next agent, whatever the harness or the machine.

This is the web interface that comes with it, handy for auditing what the agents wrote and for browsing between projects. Notice how each project lives separately, with its own page count, all of it coming out of real sessions.

Why it became 2.0

For me, the first digit of a version carries a commitment.

The 1.x line grew too fast. We went from 1.1 to 1.39 in a little over two months, stacking feature on top of feature in minor releases. It worked for iterating, but it blurred what the numbers meant.

2.0 fixes that. It bundles the few compatibility-breaking changes into a single major, and from here on versioning follows real Semantic Versioning. A fix is a patch. A new feature is a minor. Only a format or contract break is a major, and always with warning. The new contributing guide spells that rule out for any PR.

The main break is the new on-disk format. The first time you bring up 2.0, it migrates your wiki on its own. Before touching anything, it compresses your entire data directory into a verified backup with the date in the name. If the backup can’t be written and checked, the migration aborts and the server refuses to start. No “trust me”.

This is the notice that shows up once, right after the migration: it tells you where the backup landed, the file size, and how to roll back if something looks off. Once you confirm everything is fine, you just delete the backup and the reminder disappears.

OKF: your memory isn’t locked inside ai-memory

This is the change that made me happiest.

Starting with 2.0, the ai-memory wiki is, natively, a bundle in the Open Knowledge Format, the open format Google published in 2026. Each memory page is a valid OKF file: plain Markdown with standardized metadata. There’s no export step that produces a divergent copy. The wiki files already are the OKF files.

In practice that means your memory stopped being a hostage of my project. You can read it all with grep, open it in Obsidian, version it in Git, or hand the bundle to a coworker who uses another OKF-compatible tool. There’s even an ai-memory export-okf to package a whole project into a validated tarball.

That was always the thesis: the model and the harness are rented, the project’s memory is yours. Now the format backs that up in writing.

Local embeddings, on by default

Up through 1.x, real semantic search depended on you configuring an embeddings provider. Either you paid for an API and sent every page and every query out, or you spun up an Ollama on the side. Both options have a cost.

2.0 brings a local provider that runs the embeddings model inside the process itself, in pure Rust, with all-MiniLM-L6-v2. No API key, no external server, no GPU, and nothing about your data leaving the box. And now it comes on by default. On the first run it downloads the model (about 87 MB, with a fixed checksum) in the background and turns on hybrid search at the next restart.

The gain is measurable. On the LongMemEval-S benchmark, hit@5 goes from 0.617 with full-text only to 0.779 with the local embeddings. If for some reason you don’t want it, an embedding_provider = "none" turns it off.

A detail that matters: I chose candle on purpose, instead of the native runtime the competition uses. That native layer is exactly what caused a recurring kind of crash in other memory projects. I preferred not to inherit the problem.

Several agents at once, on the same project

Here’s where the part that drove most of the work before 2.0 begins.

The ai-memory run case I showed in July was sequential: I close Claude, open Codex, keep going. But what about when I leave two or three harnesses open at the same time on the same project? Claude in one tab, Codex in another, OpenCode in a third.

ai-memory handles that without anyone stepping on anyone else. Each memory call figures out on its own which project it belongs to, from the session’s directory. The “current project” pointer is now per actor, so two harnesses in the same checkout each keep their own sense of context. And the project’s identity comes from the checkout name. The absolute path on disk doesn’t count, so the same project on the laptop and on the desktop lands in the same place.

When two windows write to the same page, the second doesn’t erase the first. It creates a new version that becomes the latest, and the previous one stays reachable in the version chain. Writing something identical doesn’t create a new version. Every write goes through a single writer, with a queue and backpressure, so a burst doesn’t corrupt anything.

This isn’t theory. There’s an acceptance test calling Claude, Codex, OpenCode, Pi, Crush, and a few others for real, inside a single workstream, covering leases, session adoption, and context handoff between harnesses.

A whole team on the same project

The second scenario is the one that gives the post its title. Here it’s several people, a whole team pointing their agents at the same server.

The way to run it is simple. Someone brings up a server, usually a container in a homelab or on a machine on the network, and each person points their agents at that URL. HTTPS goes in front with a reverse proxy, if you want. The database is still a single SQLite.

Everyone sees the same project pages. What one person learned in a session, the other’s agent recovers. And each new session gets a briefing with the project’s state right at the start. I’ll be honest about the term “real time”. What exists is a shared central store, with immediate reads, plus the briefing at the open. The note a coworker wrote shows up right away for anyone’s next query or next session. A session that’s already running only gets the news at the next query or the next open, with no interruption mid-flight.

What changes in multi-user mode is attribution. Each write records who did it. There’s an audit log and the interface shows “edited by so-and-so”. That comes in the box, for free. And there’s no per-page permission, on purpose. Attribution is there to record authorship; anyone authenticated can write, and the history is what keeps track of who did.

There’s an important security distinction between what’s shared and what’s personal. The pages belong to everyone. But the handoff is a baton with a single owner: exactly one session takes it, and a second accept doesn’t steal the baton from anyone. The handoff you left pending isn’t delivered to or consumed by a coworker. Likewise, the “what I’m working on right now” slots are per person, so your personal context doesn’t leak into the whole team’s briefing.

There’s also a battery of real concurrency tests covering these cases: simultaneous writes, per-actor isolation under load, the handoff baton that doesn’t get stolen, and the personal slots that don’t leak.

Where ai-memory stands against the competition

Before 2.0 we did another round of research on the 2026 landscape, documented in the repository. It was the basis for deciding what 2.0 needed to cover. Let me summarize the field.

There’s agentmemory, a TypeScript MCP server tied to a native sidecar and a giant surface of dozens of tools. There’s basic-memory, in Python, Markdown on disk, but with manual capture: you have to ask it to remember. There’s cognee, which combines graph, vector, and relational into a heavy pipeline that wants several gigs of RAM. There’s MemPalace, which went viral with almost 50,000 stars in two weeks over a benchmark number that, once audited, turned out to be inflated, on top of suffering corruption when two writes happen together. And there are the temporal graphs like Zep, the “memory OS” like Letta (the old MemGPT), and the fact extractors like Mem0.

There’s also the native memory that Claude Code itself started turning on by default. I treat that one as the funnel that introduces the category to people. As a competitor it stays limited: tied to one machine, tied to one agent, without real search and without team history.

2.0 closes the gaps the research pointed out. We started publishing a reproducible benchmark with LongMemEval, running the actual server. We got the open OKF format. We got typed links between pages, with causes, fixes, and contradicts, which also feed a contradiction check without spending an LLM. We got queries with as_of, to ask what we knew about a subject on a given date. We got the local embeddings. And we got an optional “experience” pass that reviews several sessions to find patterns that only show up across the set.

Now the part that matters for whoever’s choosing. What ai-memory has that the others don’t, all together:

• It follows you across agents. More than twenty harnesses feed a single memory, and the handoff here is a real protocol: typed, with an owner, and claimed exactly once.
• It follows you across machines. The memory lives on a server that’s yours. The project you dropped on the desktop is the one you pick back up on the laptop.
• It works for a team. Multi-user authentication, per-person attribution, and an audit log come in the box, for free.
• Your memory is plain Markdown. The source of truth is a wiki versioned in Git. The database is a derived index you can rebuild at any moment from the files, with no vector store to babysit and nothing trapped in a binary blob.
• It captures the work on its own, quietly. No “remember this” ceremony. And the default path runs with zero LLM calls.
• It’s a single binary. No sidecar, no three databases to sync. Every write goes through a single writer, with a write ceiling we actually measured, with a real test. That design is exactly what avoided the concurrent-write corruption that took the others down.

No competitor delivers this set. Some have one piece or another. ai-memory has the whole package, and now with parity on the items where it used to fall behind.

2.0 belongs to everyone

When I wrote the July post, fifteen people had a merged PR in the project. Today it’s around seventy. This stopped being a weekend project a long time ago.

The numbers up to 2.0: more than 1,500 commits, 371 merged pull requests, and 181 closed issues. That came from people actually using it and sending fixes, features, and documentation.

I have to give special thanks to Djalma Júnior, who on his own passed 50 merged PRs, and to Samir Hanna Verza, with more than 20. Right behind come lhzapata, pedrofjr, mrpaiva, lucasliet, lihuiyang1024, Murillofilho86, and Matheus Rodrigues. And there’s a long tail of dozens of other people with a merged PR that it would be unfair to try to list in full here.

If you want in on this, the contributing guide was rewritten to make everything clear: how to set up the environment, the gates the CI enforces, the CHANGELOG rule, and the versioning policy. A bug fix usually ships fast in the next patch. A small feature, like a new harness or provider, goes into the next minor. There are issues tagged for people just starting out.

How to get 2.0

The project page has every install method, including AUR, Homebrew, and release binaries:

• ai-memory on GitHub
• v2.0.0 release notes

After updating, on the first run let the migration take the backup and convert your wiki to the OKF format. If you use the managed mode, reinstall the hooks for the harnesses you plan to use.

Conclusion

1.x proved the idea worked. 2.0 is the version I’d recommend without an asterisk for someone else to put on a team.

The format is open, so your memory doesn’t get locked in. Semantic search runs local, so you don’t pay and you don’t leak. Several agents and several people work on the same project without running each other over. And the single-binary, single-writer design is what avoids exactly the problems that sank half the competition.

The LLM and the subscription I keep renting from whoever’s best that month. The project’s memory stays with me, with the team, and now in a format nobody can take away from me.

You pay for a book, but you can only read it where Amazon allows. There is no decent native Linux app. Moving to another reader turns into an exercise in archaeology. I bought a new Xteink X4 and, naturally, my library couldn’t simply come along. The file was “in my account,” but it wasn’t under my control.

For years, I worked around this through the official route. I’d sign into Amazon’s website, use Download & Transfer via USB, download the .azw files for books I’d bought, and import everything into calibre. With the DeDRM plugin configured for my Kindle’s serial number, I’d convert them to EPUB and be done with it.

On February 26, 2025, Amazon shut that option down. No decent announcement, no replacement that actually handed over the file, and no concern for anyone who wanted a local backup. My newer books have been trapped in their ecosystem ever since. I tried again last year, updated the plugin, copied files from my Kindle Paperwhite, entered the correct serial number, and got nowhere.

To be fair, on January 20, 2026, Amazon began allowing verified buyers to download EPUB or PDF files when the publisher marks the book as DRM-free. Great. That doesn’t help with protected books, and the decision still belongs to the publisher. Older DRM-free titles must also be confirmed one by one by the publisher. This did not magically add a download button to my library.

I decided to try again now. The new DeDRM version can handle the current DRM, but the process has changed quite a bit. It takes work, requires Windows for one step, and relies on a community tool still in pre-release. It worked. I recovered 106 books I’d bought, tested the EPUB conversion, and can now read them on whatever device I choose.

This is the state of play on July 30, 2026 (updated August 19). Amazon could change the encryption or the app tomorrow. Ignore old tutorials telling you to install Kindle for PC 1.17, disable updates, and enter the device serial number in Calibre. That world is gone.

And let’s get the obvious out of the way: I’m talking about books I bought. I’m not talking about downloading Kindle Unlimited titles, library loans, or somebody else’s books. Laws covering DRM circumvention vary by country. Check the law where you live and take responsibility for what you do.

First things first: don’t throw out an old Kindle

Amazon doesn’t make it easy to repurpose an old Kindle either. The hardware remains perfectly good, the battery is usually replaceable, and an e-ink screen lasts forever, yet the software becomes increasingly closed and limited.

If you want to revive one of these devices, I recommend the Dammit Jeff channel. He covers jailbreaks, KOReader, alternative stores, and ways to keep Kindles useful after Amazon loses interest. His video about AdBreak and recent jailbreaks is a good place to start. Read the current Kindle Modding guide before doing anything, because supported firmware and methods change constantly.

Jailbreaking the device and removing DRM from an ebook are separate problems. You do not need to unlock your Kindle to follow the rest of this article. I mention both because they start from the same premise: hardware and media we’ve already paid for should remain useful without asking the manufacturer for eternal permission.

Crash course: AZW, EPUB, and KFX

DRM and file format are separate things. The format defines how text, images, fonts, the table of contents, and metadata are packaged. DRM adds a cryptographic lock on top and decides which account, app, or device can open it.

These are the three names that matter here:

The extension alone can be misleading. Pieces of a KFX book may show up as .azw, .azw.res, .voucher, and other variations. The KFX Input plugin exists specifically to understand that bundle.

EPUB is much less mysterious. The EPUB 3.3 specification defines it as a single-file container for structured Web content. It’s basically a small packaged website. Any halfway decent reader can support it without depending on a secret Amazon key.

Calibre and the two plugins

calibre is the Swiss Army knife of ebooks. It’s open source, runs on Linux, macOS, and Windows, organizes libraries, fetches metadata, edits covers, transfers books, and converts dozens of formats. It has been around since 2006 and was born precisely because the first Sony Reader didn’t work properly on Linux.

On Omarchy or any other Arch system, install the package:

sudo pacman -S calibre

For other distributions, see the official download page. Don’t install some random package from a download site.

One gotcha for environments using mise: if Calibre dies with ModuleNotFoundError: msgpack or BrokenPipeError, a Python shim probably got ahead of /usr/bin. The Arch package needs the system Python. Start it like this:

env PATH="/usr/bin:$PATH" /usr/bin/python3 /usr/bin/calibre

This has nothing to do with DRM or the plugins. It’s just Calibre’s helper calling the wrong Python. I left a permanent launcher with this PATH on my desktop.

Calibre alone does not remove DRM. We need two plugins:

1. DeDRM recognizes and removes locks from several ecosystems during import. It only runs when the book enters the library. Clicking Convert afterward removes nothing.
2. KFX Input understands Amazon’s modern containers, gathers the pieces of a book, and makes EPUB conversion possible.

At the time of writing, I’m using DeDRM 10.0.28, published on July 14 in the fork maintained by Satsuoni. It is a pre-release. Download the asset named DeDRM_tools.zip, never a standalone executable from some obscure mirror.

Update (August 2026): the Kindle app on the Microsoft Store keeps moving, and each new app version requires a new version of the tool. Since this article was published, the app moved past 1.0.18632: 10.0.29 added support for app 1.22326, and 10.0.30 supports app 1.0.22920. The practical rule is a single one: the executable’s name carries the app version it understands (MSIXKFXArchiverMobi1_22920.exe for Store app 1.0.22920, and so on). Before you start, always check the releases page of Satsuoni’s fork and grab the newest pre-release. Everything else in the process described here stays the same.

I extracted everything into a directory that would later be shared with the Windows VM:

mkdir -p ~/Windows/Kindle-DeDRM/v10.0.28
unzip ~/Downloads/DeDRM_tools.zip -d ~/Windows/Kindle-DeDRM/v10.0.28

The SHA-256 for the DeDRM_tools.zip I used was:

520cce704edf9ae26e43196efe2871daf9b25d6cb489aa56051626801c362947

Check it with sha256sum. This doesn’t magically turn a community binary into safe software, but it at least confirms that you’re using the same file I tested.

Inside that directory is DeDRM_plugin.zip. Do not extract this second ZIP. In Calibre, open Preferences → Plugins → Load plugin from file, choose DeDRM_plugin.zip, accept the warning, and restart the program.

Then go back to Preferences → Plugins → Get new plugins, search for KFX Input, and install it. My test used version 2.33.0. Restart again.

Why copying from the Kindle over USB didn’t work

The simplest path would still be plugging in my new Kindle Paperwhite, copying the book, and configuring the device serial number in DeDRM. That was the first thing I tried.

The file came in as KFX-ZIP, the plugin ran, but it remained encrypted. I opened Calibre in debug mode and the log showed that the book used the ACCOUNT_SECRET strategy. The serial number was correct. The required key no longer came from the device alone.

That’s why so many people follow an old tutorial, try five different serial numbers, and conclude that DeDRM is broken. New books with this DRM need the secret stored by the current Kindle app on Windows. That secret is protected by TPM APIs.

A disposable Windows inside Omarchy

I’m not keeping a dual-boot setup just to download ebooks. I’m also not going to pretend Wine runs everything. Fortunately, Omarchy already ships with everything needed to install and launch a Windows VM: it appears in the Omarchy menu, opens over RDP, and automatically shares ~/Windows with the guest. I didn’t have to build this integration from scratch.

Underneath, it uses dockur/windows. Dockur packages QEMU/KVM inside a container and automates the Windows installation. It remains a real virtual machine with its own disk and kernel. The container handles distribution, configuration, and lifecycle.

To install it from the terminal, run:

omarchy-windows-vm install

Choose the RAM, CPU count, and disk size. The installer creates ~/.config/windows/docker-compose.yml, stores the virtual disk in ~/.windows, and shares ~/Windows with the guest. Inside Windows, that directory appears as Shared, usually on Z:, and is also available at \\host.lan\Data.

The detail that mattered in my case was enabling TPM 2.0. Edit the generated Compose file and add TPM: "Y" to the environment block:

services:
  windows:
    image: dockurr/windows
    environment:
      VERSION: "11"
      TPM: "Y"

Then recreate the container. The Windows disk remains in the persistent volume:

omarchy-windows-vm stop
omarchy-windows-vm launch -k

The -k keeps the VM running after you close RDP. You can also watch it boot in a browser at http://127.0.0.1:8006.

Downloading the books with the right app

Inside Windows, open the Microsoft Store and install Amazon Kindle: Reading App, product 9P8JQ0JJSTLL.

Pay attention here. The old Kindle for PC installer found on blogs is not the same app. The tool I used looks for the Microsoft Store package AMZNKindle.AmazonKindleReadingApp. With the legacy program, it simply replies No AmazonKindleReadingApp installation found.

Sign in to your account and download every book you want to preserve. Opening the cover or seeing the title in your library isn’t enough. The content must be available offline inside the app.

Unfortunately, the most annoying part is still manual. Amazon found room for a one-click purchase button, but apparently not for a “download everything I’ve paid for” button.

I did this for 106 books. Yes, it was a pain in the ass.

Generating KFX-ZIP files and the K4I key

The DeDRM_tools.zip we extracted on Linux is already visible in Windows through the shared directory. Open PowerShell and switch to that directory:

cd \\host.lan\Data\Kindle-DeDRM\v10.0.28
.\MSIXKFXArchiverMobi1_18632.exe

The banner may still mention an older 1.0.15230 build. The versioned executable above looks for Store app 1.0.18632, and that’s the one that worked for me. The number in the file name must match your app version: if the Store already delivered a newer one, download the matching release from the project’s page (see the update in the plugins section).

This executable finds the current Microsoft Store app’s cache, gathers each book’s components, and produces two things:

• archived_kfx/, containing one .kfx-zip for every downloaded ebook;
• oldbooks.k4i, the keyfile DeDRM needs to open those files.

On my machine, the process found and archived 106 books. The SHA-256 of the executable I ran was:

0c78b45ccea2c36a5fbb01b9f66bdd9e5d5960a68a340ba2ee96e138f5cddf4a

It is a 32-bit binary. If it complains about a missing MSVCP140.dll, install the official Microsoft Visual C++ Redistributable x86. Do not hunt for a loose DLL on Google. That’s a great way to turn a book backup into a malware backup.

The oldbooks.k4i file is sensitive. It is derived from your account secret in that Kindle installation. Do not publish it, attach it to a GitHub issue, screenshot its contents, or put it in a public repository.

Configuring the key in DeDRM

Back on Linux, open Calibre and follow this path:

Preferences → Plugins → DeDRM → Customize plugin → Kindle for Mac/PC ebooks → Import Existing Keyfiles

Select:

~/Windows/Kindle-DeDRM/v10.0.28/oldbooks.k4i

Use Import Existing Keyfiles. Do not use the generic Set Keyfile button on the main screen. It records a different kind of key candidate and does not register the K4I key in the right place.

Close the key list, click OK in the main configuration window, and restart Calibre. If you close it with Cancel, it quietly throws the change away.

Importing and converting to EPUB

Before dumping a hundred files into the library, test one.

Choose a .kfx-zip from:

~/Windows/Kindle-DeDRM/v10.0.28/archived_kfx/

Use Add books in Calibre. Internally, the order is:

1. KFX Input recognizes the package;
2. DeDRM tries the K4I keys during import;
3. KFX Input assembles the decrypted book as KFX;
4. Calibre can now open and convert the result.

If the format still appears as KFX-ZIP, it failed. Clicking Convert ten times won’t help. Remove that entry from the library, fix the plugin or key, and import it again. DeDRM only acts on input.

When the book appears as KFX, open it in the viewer and check a few pages. Then click Convert books, choose EPUB as the output, and test the resulting file on the reader you plan to use. Only then should you run the batch import.

In my case, the KFX opened, converted, and the EPUB worked outside Kindle. That told me the entire path was working: Microsoft Store, TPM, archiver, K4I, DeDRM 10.0.28, and KFX Input 2.33.0.

Back up what actually matters

After the conversion, I preserve three things:

• the final EPUBs, which I can read on any device;
• the original KFX-ZIP files, until I’ve verified that every EPUB is intact;
• oldbooks.k4i, encrypted and stored separately from the library.

My plaintext keyfile has 0600 permissions. I also keep an encrypted copy using SOPS and age, with the private key in a separate backup. Do not put a raw oldbooks.k4i in Git just because the repository is private. Private repositories leak too.

The EPUBs follow the same strategy I use for other important files: a local copy, NAS, and off-site backup. I explained this paranoia in Protecting and Recovering Lost Data and showed the same philosophy applied to movies in My Personal Netflix.

Do not delete files from the Kindle or the VM the minute conversion finishes. Open the EPUBs and check the cover, table of contents, images, notes, and a few pages. A backup you’ve never tested is just wishful thinking.

Conclusion

Amazon has remotely deleted books, publishers update covers and content, old apps stop working, and formats change. The end of Download & Transfer via USB proved that a feature available for eighteen years can disappear with one line in a notice.

The classic example is still unbelievable: in 2009, Amazon deleted 1984 and Animal Farm by George Orwell from customers’ Kindles. Later, revisions to Roald Dahl, R.L. Stine, and Agatha Christie were pushed into digital copies people had already bought. The Vice article summarizes those cases. Dammit Jeff makes the same point often: even the original cover you chose can turn into an ugly poster for the streaming adaptation because the publisher and store decided to update your “purchase.”

It doesn’t matter whether the next change is censorship, a legitimate correction, another horrible Netflix adaptation cover, or a plain bug. I bought an edition. I want to preserve the edition I bought.

DRM does not stop piracy. A popular book lands on torrents the day it comes out. DRM only gets in the paying customer’s way, makes accessibility harder, locks up perfectly good hardware, and turns a purchase into an indefinite rental.

Calibre, DeDRM, KFX Input, and a disposable VM gave me my library back. I can now put those EPUBs on the Xteink, a Kobo, a tablet, my phone, or a reader that doesn’t even exist yet. I can switch operating systems and turn off the internet. The files stay with me.

If it isn’t on your machine, it isn’t yours.

The pattern repeats in all of them: I run into a small friction in daily life, the kind we normally swallow because fixing it would cost an entire weekend, and instead of swallowing it I open an AI agent and fix it. The cost of turning irritation into tooling dropped so much that the math flipped. Today it’s worth fixing almost everything.

Everything below is on my GitHub, with binaries, releases and install instructions.

In this post: clock-tui (with the google-calendar-tui and ghpending widgets), github-visualize, frank_geary, frank_scanlation, frank_lyrics, frank_type, distrobox-gaming and aitrepreneur-docker.

clock-tui: a desk clock that became a panel

The use case is simple: I have a secondary vertical monitor, and I wanted something more useful there than a wallpaper, something I could just glance at and get relevant information. But it all started because I just wanted a desk clock. I found a little old open source terminal clock program, the original clock-tui, which had been paused for ages, and decided to fork it and continue the work: clock-tui.

I made it prettier, modernized the Rust dependencies, and the most important change: I added support for command widgets. The clock sits at the top and below it come panels that run any command that prints text, each with its own refresh. Two widgets I built for it myself:

• google-calendar-tui: a read-only Google Calendar agenda in the terminal, using the accounts already in GNOME Online Accounts (zero OAuth setup). One glance and I know my appointments for the day.
• ghpending: lists open issues and pull requests across all the repositories I care about. Now that I have dozens of open source projects, this is how I notice within seconds when a new PR or issue arrives, without opening GitHub.

And today I spent the day adding theme support, because someone on X commented that the look could be made to resemble Evangelion. Challenge accepted: there’s now an evangelion theme (purple and lavender) and a nerv theme (red, amber and green, inspired by the show’s alert screens), switching at runtime with Shift+T. The theme is injected into the widgets via an environment variable, so the panels follow the palette.

Installing on Arch: yay -S clock-tui-bin. The widgets: yay -S ghpending-bin (there’s also brew install via akitaonrails/tap on macOS) and yay -S google-calendar-tui-bin. All of them have prebuilt binaries on GitHub Releases for those not on Arch.

github-visualize: useless, but pretty

This one was born because of Jarred Sumner’s article about rewriting Bun’s TypeScript in Rust, which I posted about recently. I don’t know which tool he used to illustrate the post, but I really liked the chart animations. Is it useless? It is. But it’s pretty, and pretty is reason enough to make a copy.

github-visualize is a self-hosted dashboard that monitors my GitHub repositories and replays their progress with animated visualizations: a commit timeline with lines added and deleted on a log scale, a commit heat map by day and hour, a CI race to green. Now I can add any repository of mine and get pretty visualizations of productivity, activity, commits and builds. Maybe I’ll use it in presentation slides, or to illustrate future posts here on the blog.

Install: public image on Docker Hub as akitaonrails/github-visualize, single container with SQLite in a volume, no external database or Redis.

Frank Geary: email the way I wanted it

I decided to use GNOME’s Geary as my main email client. It’s the closest to the interface of Apple’s default Mail app: clean, direct, no ceremony. I know, there’s Thunderbird, but I find it bloated and very ugly. There’s Mailspring, which I find bloated and heavy. My email flow is short: sweep the inbox, tag, archive and reply. Nothing else.

Geary is almost perfect, but it had two big problems for me. First: on my vertical monitor there’s much less horizontal space, and Geary has 3 fixed columns. The first column, which only lists accounts and folders/tags, I don’t need to see all the time, but there was no way to collapse it.

Second, and worse: the composer’s recipient field in practice never autocompleted anything (Geary does have the mechanism, but with a contact visibility filter so restrictive it never suggested anyone). I had to type the address by hand or copy and paste from another email. In 2026.

My first solution was two external GTK modules injected into Geary, one for each problem (both obsolete now). They worked, but they required installing Geary compiled from source, and on every yay -Syu there it went recompiling everything again.

I got tired and did what I should have done from the start: I forked Geary and created Frank Geary, which adds both features straight into the code. The sidebar now collapses, and the recipient autocompletes by consulting the contacts from your existing emails. I’ll keep maintaining the fork by rebasing from upstream frequently.

And the best part: there’s now a package on the AUR, so installing goes like this:

yay -S frank-geary-bin    # prebuilt binary (x86_64), from the GitHub release
yay -S frank-geary        # or compiling from source

Both packages replace the system’s geary (they provide/conflict with it), so the swap is clean and updates arrive like any other package. One detail after installing or upgrading: when the watch-for-new-mail option is on, Geary keeps running in the background as a D-Bus service, so run a geary --quit to make sure no old process is left hanging around.

Japanese manga: FrankYomik, FRANK MANGA+ and FRANK Scanlation

Anyone following the blog knows about my love for Japanese manga. I already posted about FrankYomik, which was born so I could read the original Japanese manga I buy from Amazon Japan.

The problem: manga aimed at adult audiences (no, not porn! I’m talking about subjects like business or military topics) doesn’t have “furigana”, the little kana subtitles printed next to difficult kanji, indicating the reading. Shounen manga has furigana on everything, so you can read it with student-level vocabulary. The adult ones assume you already know how to read the rare kanji. I don’t.

FrankYomik solves that by adding furigana on top of the page, in real time: a model detects the speech bubbles, manga-ocr extracts the text, and the furigana (or a full translation, via a local LLM on Ollama) is rendered on top, all running on my own hardware. And the important detail: on-the-fly, over the image I already have legitimately open, without downloading or redistributing a single page, so no copyright or license infringement.

Then came FRANK MANGA+, which I also posted about. I pay for the subscription to Manga Plus, Shueisha’s official app, but it only lets me read on mobile (Android/iOS). On a small tablet it’s tolerable, but I have a 32" Samsung Odyssey OLED monitor sitting right in front of me.

I figured out how to use my own subscription outside the app and built a desktop reader in Tauri: it runs on Linux, macOS and Windows, the free tier works out of the box and subscribers paste their own secret to unlock the premium chapters.

Install: AppImage, .deb and .dmg on the releases, or yay -S mangaplus-reader-bin on Arch.

And finally, I also read the occasional community “scanlations”: fans scan the pages of the original Japanese manga and translate them (nowadays most use AI in the process, there are even models trained to recognize speech bubbles, and I used one of those in FrankYomik itself). These scanlations are spread across several different websites, like MangaDex.

First I made a Chrome extension to prettify those sites (obsolete now), but I got tired of living with dozens of tabs in Brave just for scanlation sites. So I built FRANK Scanlation, along the same lines as FRANK MANGA+: a desktop app that concentrates all my favorite scanlations in one place, with a library, per-title reading progress and checking for new chapters.

The reading windows load the site itself and inject a decent reader on top, with double-page spreads and keyboard navigation. Nothing is hardcoded to any website: they’re heuristics that detect image sequences and chapter numbering in any URL. It became my preferred way to read the manga that can’t be bought on Amazon or from Shueisha.

Install: AppImage, .deb and .rpm (and a macOS build) on the GitHub releases.

Frank Lyrics: memorizing songs line by line

I already posted about Frank Karaoke, a little app to add scoring on top of YouTube and enjoy karaoke with family and friends. But there’s a sibling use case: I like learning new songs (a new anime opening, for example), and the process of memorizing lyrics is repeating the SAME line several times. In the YouTube player that’s hell: you keep hunting by hand for the exact spot on the timeline to go back to, miss it by two seconds, rewind too much, overshoot.

To solve that I created Frank Lyrics, a simple Chrome extension that figures out the correct timing for each line of the lyrics using the public markers from LRCLIB and injects controls into the YouTube page itself. LRCLIB, for those who don’t know it, is an open, community-driven library of synchronized lyrics: each line comes with a timestamp (the classic LRC format from music players), with a public API, free and keyless.

The extension matches those timestamps to the video and gives me buttons to repeat the exact line I’m memorizing, as many times as I need, without hunting the timeline. If you enjoy karaoke, the Frank Karaoke + Frank Lyrics combo should serve you well.

Install: download the .zip from the releases, unzip it, open chrome://extensions, enable developer mode and “Load unpacked” pointing at the folder.

Frank Type: typing practice with actual prose

Anyone who has followed me for a while knows I love my keyboards. There are videos on the Akitando channel about it and posts here on the blog about my favorite keyboards. And from time to time I like to train on MonkeyType. But I dislike typing random words. TypeRacer solves that by using real public texts, except it makes me wait for other players in the room (I hate multiplayer games). In other words: I wanted a single player experience, with real prose, but with the MonkeyType aesthetic, which I prefer.

So I created Frank Type, a mini-clone of both: a typing trainer in Rails 8 that uses normalized public-domain prose excerpts instead of random word lists. It’s local-first and account-free: session history, timing data and profile charts stay in the browser’s local storage. It even has a digraph heat map to show which key combinations slow you down.

Install: it’s a Docker container published as akitaonrails/frank_type. One command brings it up at http://localhost:3200:

curl -fsSL https://raw.githubusercontent.com/akitaonrails/frank_type/master/bin/docker-run.sh | bash

distrobox-gaming: a library of how to install games on Linux

I game on the same PC I work on, but I refuse to mix emulator packages and Wine hackery with my development environment. The solution was to isolate gaming entirely inside a distrobox (containers that integrate with your desktop as if they were native), and distrobox-gaming is the repository of Ansible playbooks that builds that Arch box from scratch: ES-DE as the frontend, standalone emulators, RetroArch cores, per-game configs. My Arch/Omarchy host stays clean.

The rule I imposed on myself: every new game I install has to become a reproducible Ansible recipe. I confess I haven’t tested the full rebuild from scratch yet, but that’s the idea: any trick or hack required gets documented in code instead of lost in shell history.

And there’s no shortage of tricks, because I’ve been installing old abandonware: the Colin McRae Rally series (from the PS1 version with a 60 fps patch up to 2007’s DiRT), Sega Rally Revo, OutRun 2006 Coast 2 Coast, among others. Each with its own Wine quirks, patches and configs. Without meaning to, the repository is becoming a library of documentation on how to install games, emulators and retro games on Linux.

Along the same lines there’s distrobox-llm, which does the same isolation for my local LLM environment (CUDA, Ollama, LM Studio and friends), leaving only the NVIDIA driver on the host.

Install: clone the repository and run the playbooks:

cd ansible
ansible-galaxy collection install -r collections/requirements.yml
cp host_vars/localhost.yml.example host_vars/localhost.yml
$EDITOR host_vars/localhost.yml
ansible-playbook site.yml

aitrepreneur-docker: ComfyUI without dirtying the system

For image generation I like ComfyUI, and I posted about it last year. I follow a youtuber called Aitrepreneur who maintains a Patreon page with recipes to install and configure ComfyUI with the newest models and workflows. His curation work is great, but the recipes are old school .sh scripts, meant to run as one-shots on a RunPod instance, for example.

Now that LLMs evolved to the point of writing decent Dockerfiles, I created aitrepreneur-docker, which converts those scripts into proper Docker images and containers: pinned versions, persistent data on the host or NAS, one command to bring up or upgrade each app. That way I run everything isolated on my machine, without littering my Linux with tons of Python packages and hacks that could destabilize the system.

Two important notices. The credit for the stack selection, model curation and workflows all goes to Aitrepreneur: the repository only translates his work into Docker form, and his original scripts are paid Patreon content that is NOT included.

If you find it useful, subscribe to his Patreon to contribute to his content creation (that’s also where you get the original files). And the repository doesn’t cover everything he has produced, only the most recent recipes.

Install: git clone, make setup (creates the .env for you to put your Hugging Face token), make build and make up.

And there’s more where these came from

If you’re new here: this is just the batch that hadn’t shown up on the blog yet. There are plenty more projects I’ve covered in dedicated posts. ai-memory is the most popular, most used and most contributed-to of all. ai-jail, which showed up again in yesterday’s post about destructive agents, was the first of the series and is the second most popular.

And there are the others in the Frank series (“Frank” in honor of Frank Rosenblatt, creator of the perceptron, the original neural network; the name marks the experimental projects I do for fun):

• Frank Sherlock: smart image indexer
• Frank Mega: MEGA clone for my home server
• FrankMD: markdown editor
• Frank FBI: email fraud analyzer
• Frank Investigator: teaches you to question the news

Everything is open source and on my GitHub. Everybody is welcome to contribute with issues, pull requests, or just by sharing with your friends. Each of these projects was born from a real little problem of mine. Maybe one of them solves yours too.

This week a curious controversy showed up in the open LLM world: Rio 3.5 Open 397B, presented by the City of Rio / IplanRIO in the Rio 3 Open announcement as an open model.

The accusation: in practice, the published checkpoint, meaning the model weights file, was a direct blend of Nex-N2-Pro and Qwen3.5-397B-A17B, without initial credit to Nex.

The question mark in the title is intentional. “Plagiarism” is a loaded word, especially when we’re talking about a model under a permissive license. The right question isn’t only “can they use it?” In open source, most of the time they can. The question is: did they use it, modify it, redistribute it, and give proper credit? And for an AI model, there’s another question just as important: were they transparent about what was actually done?

My short conclusion before the long version: Nex’s public evidence is strong. Strong enough to say the initially published Rio 3.5 checkpoint looks like an almost linear blend of Nex-N2-Pro and Qwen3.5-397B-A17B.

Rio’s own README was changed after the Nex issue to acknowledge Nex + Qwen and say there had been an “incorrect upload”.

I did not reproduce the tensor-by-tensor analysis myself. I’m evaluating the evidence Nex published, the public Hugging Face history, and the tests I ran separately in my own benchmark.

This does not prove, legally, “plagiarism” in the classic sense. But it shows a serious attribution and communication failure. And for a public-sector project, with a city government involved, that matters more.

What the City of Rio announced

In April, the City published a note saying IplanRio had presented Rio 3 Open, “a family of six cutting-edge artificial intelligence models, fully free and open.”

The official text said the idea was to make Rio recognized as a public innovation hub, capable of developing its own AI solutions “without depending on foreign platforms.” It also highlighted an MIT license, free use, modification, and even profit from the technology. Source: City of Rio, 2026-04-02.

A Mobile Time article gave more context: the family would be developed from Qwen, Alibaba’s Chinese model.

João Cabaretta, president of IplanRio, reportedly said: “What we did was take the Qwen model, already ready, and from it we modified the model.” The article also listed expected city use cases: reading security cameras for suspicious activity, analyzing accountability documents, generating institutional images and videos, and citizen service.

So far, nothing absurd. Taking an open model and adapting it for local use is exactly what many people do. If the city managed to assemble infrastructure, adapt a model, document it, and publish weights, good. I’m in favor of that. I prefer it over another closed contract with a foreign SaaS nobody can audit.

The problem starts with how Rio 3.5 was presented.

On Hugging Face, the prefeitura-rio/Rio-3.5-Open-397B repository initially said the model was “developed by IplanRIO”, “Post-trained from Qwen 3.5 397B”, with MIT License, and acknowledgments to the Qwen Team and SwiReasoning. That older version is still accessible in the Hugging Face history: README before the correction.

The card also promised a frontier-class general-purpose model, with 397B total / 17B active parameters, a 1,010,000-token context window, and commercial/research use under MIT. In other words: this wasn’t a footnote. It was an ambitious release.

Notice the detail: Qwen appeared as the base. Nex did not.

And this matters because, in Nex’s own discussion, someone corrected the narrative by saying Rio had credited Qwen early on. That’s true: the second model-card commit already listed base_model: Qwen/Qwen3.5-397B-A17B. A comment in the issue points this out too: “They did say Qwen 3.5 397B was the base model from the beginning…”.

So the stronger accusation isn’t “they omitted Qwen.” It’s: they credited Qwen, but omitted Nex-N2-Pro, exactly the component Nex’s weight analysis says was the majority ingredient in the published recipe.

After Nex opened the issue, the current README said something different:

“The model was built through a merge of https://huggingface.co/nex-agi/Nex-N2-Pro and https://huggingface.co/Qwen/Qwen3.5-397B-A17B, followed by On-Policy Distillation from a stronger model. We detected an incorrect upload in the previous version, where the merged base version was uploaded instead of the final distilled model. We apologize for the confusion.”

Source: current Rio 3.5 README, changed in commit a778c1e.

That sentence changes the story a lot. Before: “post-trained from Qwen.” After: “blend of Nex-N2-Pro and Qwen, followed by distillation, but we uploaded the wrong file.”

That may be true. There may really have been a wrong upload. But as an outside observer, I can only analyze what was published.

Nex’s accusation

Nex opened issue nex-agi/Nex-N2#4 on June 14. In my translation/summary, the core accusation is direct:

prefeitura-rio/Rio-3.5-Open-397B is presented as an original 397B model trained by IplanRIO. It is not. Its weights are a direct element-wise blend of our model, Nex, with the official Qwen3.5-397B-A17B base — about 0.6 Nex / 0.4 Qwen — and we find no evidence of their own training.

Nex points to two lines of evidence.

First: identity behavior. According to them, Rio’s service used a built-in system prompt saying “You are Rio”. With that prompt removed, they asked 120 identity questions. The reported result was:

• “Nex”: 95/120, or 79.2%.
• “Nex-AGI”: 88/120, or 73.3%.
• “Rio”: 0/120.

Example response cited by Nex:

“I am Nex, from Nex-AGI. Nex-AGI is a large-model ecosystem alliance, jointly built by the Shanghai Innovation Institute…”

Source: Nex comment on identity behavior.

That alone doesn’t prove everything. A model identifying as another model can happen because of dataset contamination, system prompt, a bad test prompt, or reused fine-tuning. But it’s a bad sign when a supposedly “Rio” model never says “Rio” without the mask and says “Nex” very often.

The second piece of evidence is more serious: weight analysis.

Nex’s hypothesis is simple. If Rio = α·Nex + (1−α)·Qwen, then for every tensor:

(Rio − Qwen) ≈ α · (Nex − Qwen)

They report very consistent values: routed experts with α ≈ 0.571 ± 0.0016 and cos_fit 0.993; lm_head with 0.574 and 0.991; attention around 0.585 and 0.986; linear-attention projections around 0.586 and 0.984. Source: Nex comment on weight analysis.

This is the part that carries the most weight. High similarity between models in the same family would not be surprising. But tensor-by-tensor collinearity at this level is a different thing. If the equation reproduces across all tensors, it doesn’t look like “we trained something similar.” It looks like a merge.

The weak point: until someone reproduces it independently, this is still an analysis presented by an interested party. The strong point: it’s falsifiable technical analysis, not just a screenshot of a chat.

Nex’s tweet

Nex’s tweet summarizes the accusation in meme form:

“The Rio 3.5 model broke the internet this week. The plot twist? It’s essentially our open-source model, Nex N2 Pro, wearing a different hat.”

And continues:

“We analyzed the weights, and the recipe is exact: Rio 3.5 ≈ 0.6 * Nex N2 Pro + 0.4 * Qwen 3.5”

It also repeats the identity claim:

“It even literally introduces itself as ‘Nex N2 Pro’ if you ask it without initial system prompt!”

And closes with the most important sentence:

“But in the open-source world, attribution matters.”

That’s it. The most important part isn’t “they used our model.” Open models exist to be used. If the analysis is correct, the complaint is: they allegedly used it, benefited from inherited performance, announced results, but only gave credit after Nex exposed the blend.

But what is Nex-N2-Pro?

Before going further, it’s worth explaining who Nex is in this story, because it didn’t come out of nowhere either.

In the official model card, Nex describes Nex-N2 as “an agentic model with Agentic Thinking”.

Marketing aside, the promise is clear: not just a good chat model, but a model tuned for long agent tasks. Coding, tool calls, terminal execution. The annoying kind of workflow where the model needs to plan, execute, see environmental feedback, fix things, and iterate.

And yes: it is also based on Qwen. The card itself says the two models in the family were post-trained on top of the Qwen3.5 series:

• Nex-N2-Pro: built on Qwen3.5-397B-A17B.
• Nex-N2-mini: built on Qwen3.5-35B-A3B-Base.

So Nex is not saying “we created a base architecture from scratch.” It is saying: we took Qwen as a base and did agent-focused post-training on top. The promised difference is in that post-training.

They call the framework Agentic Thinking, split into two ideas:

• Adaptive Thinking: the model decides when to think less and act quickly, or when to spend more reasoning on critical decisions.
• Coherent Thinking: keeping one consistent reasoning paradigm across general tasks, coding, and agent tasks, instead of treating reasoning, tool use, and execution as separate islands.

There are practical details too: they recommend a customized fork of sglang, use reasoning-parser qwen3, tool-call-parser qwen3_coder, talk about robust function calling, and list agent/coding benchmarks where Nex-N2-Pro would land close to proprietary models like GPT-5.5 and Opus 4.7.

Of course, vendor benchmarks always need salt. But the thesis is this: raw Qwen is the base; Nex is the agent post-training and packaging that should turn that base into a better model for real agent work.

That matches my independent benchmark. Qwen3.5-397B-A17B base did badly: 42/C. Nex-N2-Pro did well: 83/A. Same base, brutal difference. At least in my Rails/RubyLLM test, Nex’s value doesn’t seem to be “it has 397B parameters.” Qwen already had that. The value is in fixing agent behavior the Qwen base did not have: using a real API, finishing the task, validating the environment, handling errors.

That distinction matters for the Rio controversy. If Rio 3.5 used Nex as the main ingredient, it’s not just “Qwen under another name.” It would have used precisely the part that made Qwen useful for agent tasks. And that part was Nex’s work.

What Rio effectively answered

The most concrete public answer I could verify was the README change on Hugging Face. Rio now says:

1. The model is built through a merge of Nex-N2-Pro and Qwen3.5-397B-A17B.
2. After that there would be an On-Policy Distillation step from a stronger model.
3. The initially uploaded checkpoint was the “merged base version”, not the final distilled model.
4. They were working to reupload the correct model.

The Hugging Face commit history also shows that, after the issue, many files from model-00001.safetensors through model-00097.safetensors and a benchmark image were removed. You can see it through the Hugging Face commits API.

Here comes my normal engineer skepticism. “We uploaded the wrong file” is a possible explanation. It happens. But when the wrong file, according to Nex’s analysis, is exactly a mathematical combination of upstream models with no initial credit, and the correction arrives an hour after the accusation, it’s hard to call it a mere operational detail.

Not impossible. Hard.

What model merging is

For anyone not following this niche, model merging isn’t magic. It’s a fairly common technique: you take two compatible checkpoints, usually from the same architecture, and combine the weights. The simplest version is literally a linear interpolation:

final_model = 0.6 * model_A + 0.4 * model_B

There are more sophisticated variations: layer-wise merge, task vectors, TIES, DARE, SLERP, different weights per module. But the concept is this: you’re not training from scratch. You’re combining already trained parameters.

Can this work? Sometimes. Especially when the models share the same base and were tuned in complementary directions. It can preserve capabilities from one and recover base behavior from another. It can also make things worse. Merging is statistical alchemy: there is technique, but also a lot of empirical testing.

And, most importantly: merging costs nowhere near what it costs to train a 397B model. You need to download huge checkpoints, run scripts, test weights, maybe benchmark, maybe tune a few things. It is not zero work. But it is not “we trained a frontier model.”

If Nex’s evidence is correct, the published checkpoint was something like:

Rio 3.5 ≈ 0.57 to 0.60 * Nex-N2-Pro + 0.40 to 0.43 * Qwen3.5-397B-A17B

That looks more like integration engineering than model training. It is not the same kind of technical merit as post-training or distilling a 397B and presenting it as your own advance.

What distillation means here

Distillation is a different thing. In LLMs, it usually means using a stronger teacher model to generate answers, reasoning traces, or preferences, and training a student model to imitate that behavior. You can distill style, reasoning ability, response format, a specific domain, tool use. The student can be smaller, cheaper, faster, or simply adapted to a goal.

Rio’s corrected README says On-Policy Distillation from a stronger model. Roughly translated: they would have used a stronger model to generate training data or signals under a generation policy closer to the student itself, and then trained the final Rio 3.5.

That, if it exists, is real work. It requires a pipeline, data, compute, evaluation. The issue is that Nex did not analyze this alleged final distilled model. It analyzed the checkpoint that was public. And Rio now says that checkpoint was the “merged base version” uploaded by mistake.

So the factual state is:

• initially published checkpoint: accused of being a Nex + Qwen merge;
• initial README: credited Qwen, not Nex;
• corrected README: acknowledges Nex + Qwen merge and says the final distilled model was not that file;
• correct final model: still open, until it is reuploaded and analyzed.

Without the final checkpoint, we can’t evaluate the distillation. We can evaluate the communication.

The license: Apache allows it, but usually requires preserving notices

This is where a lot of online discussion gets dumb.

I am not a lawyer and this is not legal advice. Also, the exact application of open-source licenses to model weights still has gray areas. But in a practical reading of Apache-2.0, the operational rule is not “use it and erase the traces.”

Nex-N2-Pro declares Apache-2.0 on Hugging Face: Nex-N2-Pro README. Qwen3.5-397B-A17B also declares Apache-2.0: Qwen3.5-397B-A17B README.

Apache-2.0 is permissive. It allows reproduction, modification, derivative works, sublicensing, and distribution. Commercially too. So it is not “theft” simply because they used Nex and Qwen. If the license allows use, use is part of the game.

But permissive does not mean “no obligations at all.” The Apache-2.0 license requires, among other things:

• giving recipients a copy of the license;
• marking modified files with prominent change notices;
• preserving copyright, patent, trademark, and attribution notices from the source form;
• including NOTICE when the original work has an applicable NOTICE.

Rio 3.5 initially declared MIT License and credited Qwen/SwiReasoning, but not Nex. If the distributed checkpoint was in fact derived from Nex-N2-Pro, that is at least an attribution failure. It may be fixable. It seems to have been partially corrected in the README. But the error happened at launch, exactly at the moment of highest visibility.

And there is another nuance: you can’t simply take two Apache-2.0 components, generate a derivative, and announce the resulting package as if it were only MIT, without preserving the Apache obligations from the upstreams.

Apache-2.0 is permissive and allows you to distribute derivatives under different terms for your modifications, but with conditions: you still need to provide the Apache license, preserve copyright/attribution notices, and carry NOTICE when one exists.

So “MIT” may appear as the license for Rio’s added layer, but it cannot erase Apache-2.0 from Nex and Qwen or imply the whole derivative is free of those obligations. If the original card said only MIT and did not include the applicable Apache credits/notices, that can stop being just an etiquette slip and become a possible license-compliance problem.

There’s an irony here: they could have avoided 90% of the controversy with one honest sentence from the start:

“Rio 3.5 is a merge/fine-tune built on Nex-N2-Pro and Qwen3.5-397B-A17B, with IplanRIO adaptations for Portuguese and public-sector use.”

Done. Maybe people would still complain politically, but the technical criticism would be much weaker. The problem is looking like you did it alone.

How much work does it look like?

This is the speculative part, so I’ll mark it as speculation.

If what was published was only the base merge, the technical work may have been much smaller than the public narrative suggested. Merging two giant models is not clicking a button in a browser, of course. You need storage, scripts, machines, validation, shard handling, uploading almost a hundred safetensors, tests, documentation. It is operational work.

But it is not the same kind of work as truly training, post-training, or distilling a 397B.

And the phrase “open AI model trained in Rio with public funding over the last year,” as Eduardo Cavaliere said in this tweet, creates a very different expectation from “we merged two Apache models and maybe distilled afterward.”

Rafael Coelho replied in another tweet that they had not spent public money and had swapped old training code for GPU credits. There may be an administrative explanation there, but from the outside the communication is confusing.

I am not claiming administrative wrongdoing. I am saying the public narrative became inconsistent.

And even the R$ 500,000 figure, cited by Mobile Time about the previous generation, needs scale. In serious LLM research, that is not a lot of money. Add salaries for a few researchers, infrastructure, storage, cloud GPU hours, failed attempts, evaluation, data engineering, and that amount disappears quickly. It’s a drop in the ocean compared with the cost of training or post-training a genuinely large model.

So I would not use “R$ 500,000” as automatic proof of waste. That’s not the point. The point is different: that amount also does not, by itself, support a narrative that a heavy, original 397B training run happened. For that kind of scale, serious research would spend much, much more.

Was it publicly funded? Was it not? Did it cost R$ 500,000 in the previous generation? Was it GPU credits? Was it a year of training? Was it a merge? Was it distillation? Was it a wrong upload?

Maybe all those sentences have different contexts. But when technical communication is bad, the public stitches everything together and it becomes a mess.

What my benchmark says about Nex and Qwen

Now comes the part where I can speak from my own data. In my llm-coding-benchmark, I tested both Nex-N2-Pro and the Qwen 3.5 397B A17B base.

My benchmark measures one specific programming/Rails task. It is useful as a signal, not as a general capability evaluation.

I did not test Rio 3.5 directly for a simple reason: it is too large for my local machine. My Strix Halo has 128 GB of unified RAM, great for many things, but not enough to run a 397B model like this comfortably. To test it properly, I would need to rent a cloud machine, deal with setup, download hundreds of gigabytes, organize shards, start an inference server, pay by the hour, and still risk the correct checkpoint not even being available at that moment.

I was not up for all that work for a quick analysis post. So I used the best available approximation: test the originals that the controversy itself puts in the recipe, Nex-N2-Pro and Qwen3.5-397B-A17B. If the published Rio was basically a merge of those two, and if there is no public evidence of much effective work on top of that checkpoint, comparing the ingredients already says a lot. It does not replace a direct Rio test, but it puts the performance claim in perspective.

There’s another detail: in Rio’s own old model card, the table said “Gains Over Base Model”, but Rio did not beat Qwen 3.5 base on everything.

It lost on MMLU-Redux (94.6 vs 94.9), MMMU-Pro (78.4 vs 79.0), and VideoMMMU (81.6 vs 84.7), tied on MCP-Atlas (74.2 vs 74.2), and in some cases won by small margins, like MMLU-Pro (88.0 vs 87.8) and MathVision (89.1 vs 88.6). So even by the self-reported numbers, without independent auditing, the story was more “improves on several benchmarks” than “better than Qwen at everything.”

And yes, where Rio said it beat Qwen, that also fits Nex’s hypothesis: Nex-N2-Pro was already better than the Qwen base precisely because of Nex’s work. I saw this in my own benchmark: Qwen3.5-397B-A17B base scored 42/C, while Nex-N2-Pro scored 83/A. So a Rio that mixes Nex with Qwen can very well look better than Qwen. For the published checkpoint, the simpler explanation is not “Rio invented a miracle technique”; it’s “it inherited much of the gain Nex had already produced on top of Qwen.”

Relevant commits:

• 11a9c68: adds Nex-N2-Pro, 83/100, Tier A.
• e2af88c: adds Qwen 3.5 397B A17B base, 42/100, Tier C.

In the final benchmark table, Nex landed here: rank #10, 83/100, Tier A.

Nex-N2-Pro | 83 | A | RubyLLM OK | OpenRouter | 25m | free

The Qwen base landed here: rank #28, 42/100, Tier C.

Qwen 3.5 397B A17B (base) | 42 | C | RubyLLM not OK | OpenRouter | 15m | ~$0.58

That’s an interesting control. Same backbone, completely different result.

The Qwen base hallucinated the RubyLLM API (chat.system, chat.user, response.text) and even created the app inside a nested chat-app/ directory, violating the expected benchmark shape.

Nex, on the other hand, used the real API: RubyLLM.chat, chat.ask, response.content, booted locally, passed Docker, compose, and real chat through OpenRouter. The report compares it directly: Qwen base 42/C vs Nex tuned 83/A, a 41-point jump.

That puts Rio 3.5 in perspective. If it really was 60% Nex + 40% Qwen base, it makes sense that it would inherit a lot of Nex’s agent capability. But it also makes sense to suspect that mixing in 40% of a model that did much worse in my programming test could degrade pure Nex in some scenarios.

So I won’t claim “Rio is worse” as my own measurement. What I can say is: the Nex component is good; the Qwen base component was bad in my test; a Rio that was only Nex diluted with Qwen base should not be sold as an obvious advance over pure Nex without a reproducible benchmark against Nex itself. From what has been published so far, it does not look like the work on top of the merge improved the ranking in a demonstrable way. If it did, publish the correct model and reproducible tests.

And even Nex, which did very well, was not at the top of my open or open-ish ranking. It scored 83. The best so far were Kimi K2.6 and GLM 5.2 at 87, and Kimi K2.7 Code at 86. Nex is Tier A, free, impressive. But it is not magic. It is a good agent-focused fine-tune on top of a family that, raw, badly trips on library APIs.

So as a user, my practical conclusion is simple: if I had to choose today, I would use Nex-N2-Pro directly. Not because Rio is automatically useless forever, but because the published checkpoint did not show a clear, auditable gain over the most valuable ingredient in the recipe. If the gain came from Nex, why not use Nex? Rio becomes technically interesting again only if the correct final distilled model appears, with reproducible evaluation showing a real advantage over pure Nex-N2-Pro.

So was it plagiarism?

My honest answer: I would not call it plagiarism as a legal conclusion. I would call it a poorly attributed repackaging of the initially published checkpoint, with strong evidence of a direct merge and a correction that only appeared after exposure.

Open source is not “you can’t use it.” Open source is “you can use it, but respect the license and give credit.” If Nex and Qwen are Apache-2.0, the city could build on top of them. It could merge. It could distill. It could publish a derivative. It could even license its own layer under MIT, as long as it does not erase the Apache obligations from the components and preserves the required notices.

The mistake was letting the public narrative look like an original creation, with incomplete credit. And then, when Nex showed up with tensor-by-tensor math, the README changed.

Maybe there is a real final distilled model. If there is, publish it. Preferably with:

• a clear card stating the base, merge, distillation, and training data;
• a license compatible with Qwen and Nex;
• explicit credits;
• a reproducible evaluation script;
• a benchmark against pure Nex-N2-Pro and Qwen base;
• an explanation of the “incorrect upload.”

That would close much of the technical discussion. Maybe not the political one, but the technical one, yes.

What to learn from this

This story is a good reminder for everyone surfing open models now. The derivation chain matters. Not because of academic bureaucracy, but because it is part of trust.

If you fine-tune on top of Qwen, say Qwen. If you merge with Nex, say Nex. If you distill from a closed teacher, say you distilled, even if you can’t name the teacher. If you uploaded the wrong checkpoint, explain exactly which one was wrong, which one is right, and how someone can verify it.

The worst path is trying to look bigger than you are. Because open LLMs are an environment where weights can be downloaded, compared, and audited. You can hide the narrative for a while, but you cannot hide linear algebra.

In the end, Nex may have received the best involuntary validation of its own model: if a city government used Nex-N2-Pro as 60% of the recipe for a model announced as “state of the art,” then Nex is good. But involuntary validation does not pay the credit bill.

And credit, in open source, is not fussiness. It is the basic currency of the game.

I like this phase. The project stops being “what I imagined in my setup” and becomes “what breaks on somebody else’s machine.” Then Windows shows up. macOS. Arch. AUR. Weird paths. Tokens saved somewhere else. Different shell. Different terminal. Annoying? Yes. Necessary? Also yes.

But today’s main dish is not ai-jail or ai-memory. It’s TUI. More specifically, my recent habit of writing small terminal tools in Rust with Ratatui, while wanting them to look like Bubble Tea.

The app I won’t open

Over the last few weeks I also worked on a private project I do not plan to open source. It’s a TUI to track my US bank account, investments, assets, positions, covered calls, open calls, all that boring grown-up stuff. I won’t publish the code because this tool was born glued to my financial workflow, my spreadsheets, my statements, and my internal hacks. Opening it would turn a tool for myself into free support for other people’s bank bugs. No thanks.

But I can show the general look. I censored what needed censoring:

Obvious note, but I’ll make it explicit: every value, ticker, position, and date shown in the screenshot is bogus demonstration data. It is not real account data, not my real portfolio, and not investment advice.

Every time I build a small TUI, the same question comes back: what stack should I use?

If I were writing everything by hand, I would probably pick Python or Go. They are more comfortable for this kind of small utility. Python because it is direct, full of libraries, great for scripts that talk to APIs and parse JSON. Go because it produces simple binaries, cross-platform support is sane, and the CLI ergonomics are good.

But today I rarely write all that code by hand. I orchestrate Claude, Codex, OpenCode, ask for reviews, ask for refactors, ask for tests. In that setup, Rust’s lack of ergonomics hurts less, because the LLM is the one fighting the borrow checker, trait bounds, and annoying lifetimes. I stay closer to reviewer and end user. And then Rust starts looking very attractive.

Good tooling. cargo is great. Tests are easy to run. Cross compile is manageable. The final binary is clean. Dumb memory bugs mostly disappear. I am not saying Rust is magically better than Go or Python for every TUI. It isn’t. But with an LLM writing most of it, the cost that would usually make me avoid Rust drops a lot. And current models are surprisingly competent with Rust, as long as you make them run tests, fix warnings, and you don’t accept the first version as if Moses brought it down from the mountain.

Ratatui is good, but I wanted the Charm look

Ratatui is a Rust library for building full terminal interfaces: dashboards, interactive apps, tables, lists, gauges, layouts, the whole thing we used to call “modern ncurses.” It grew out of tui-rs, and today it is probably the obvious path if you want to build a serious TUI in Rust.

Ratatui works well. My problem is taste: by default, I don’t find it pretty. Not ugly in the “this looks like a DOS program from 1993” sense. You can build good-looking stuff with it. But many Ratatui TUIs fall into that square, gray, functional look, like a datacenter admin panel.

I like the Charmbracelet vibe more. gum, for example, is a collection of commands that make shell scripts interactive without turning them into a festival of read -p and case. Prompt, select, filter, spinner, table, pager, styling. You can make a bash script feel like a decent app in minutes.

And then there is Bubble Tea, in Go, inspired by Elm architecture. You have a model, receive messages, update state, render a view. Simple idea, very good fit for terminal apps: state comes in, event comes in, view goes out. Charm also has visual taste I like: good colors, decent spacing, light components, nothing that looks like a WinForms form thrown into a terminal.

So I wanted this: stay in Rust with Ratatui, but steal the feeling of Bubble Tea. Not the whole runtime. Not a perfect clone. Just the visual direction and a few components.

That is how ratatui-bubbletea was born.

The project does not replace Ratatui. It sits on top. The idea is to offer a theme and component layer inspired by Bubble Tea/Bubbles, while still rendering through Ratatui.

Right now it is split into crates:

• ratatui-bubbletea-theme, with palette, helpers, and shared styles.
• ratatui-bubbletea-components, with ready-made components like select list, spinner, progress, table, text input, viewport, and help.
• ratatui-tea, optional, for people who want ergonomics closer to Model, Msg, and Cmd, without pretending Rust became Go.

The README has the full examples and documentation for what exists today. For now, I treat it as a small toolkit. It serves my apps, and if it serves somebody else, fine. If it doesn’t, no drama either. The goal was to stop reimplementing the same theme and the same widgets every time I started a new TUI.

ai-usagebar as the public example

Since I won’t open the financial app, I needed a public example using this aesthetic. So I updated my ai-usagebar.

If you don’t remember it, I explained the project in “I Built a Waybar Widget for Omarchy to Monitor LLM Plan Usage: ai-usagebar”. It started as a Waybar widget to show LLM plan usage: Claude, OpenAI Codex/ChatGPT, Z.AI, OpenRouter. One glance at the bar and I know whether I am close to the limit and which vendor to use next.

Later it also became a standalone TUI. And thanks to contributions, it now supports Windows too. That is funny because its origin is completely Linux/Omarchy/Waybar. But that is open source: somebody uses it in another environment, finds friction, sends a PR, and now the project is a little less provincial.

In ai-usagebar, the visual change will not alter anybody’s life. It is a simple screen. Tabs, gauges, text, shortcuts. But it is a good example because it is small, real, tested, packaged, and does not depend on my private app. You can look at the code and see how I applied the theme layer.

The scratch-my-own-itch apps

All these projects follow the same logic: I have an itch, I make a small tool, I use it, adjust it, package it. No startup roadmap. No manifesto. Just a tool that fixes something annoying in my own setup.

One recent example is clock-tui. It did not start with me. It was an old Rust project, tclock, that looked abandoned. I wanted a big clock on my second vertical monitor. That monitor sits on the side, and I like having a huge desk clock taking up part of the screen. I used the original clock-tui for a while.

But an entire vertical screen just to show the time is wasteful. I already had ghpending, which lists open issues and PRs across all my projects. It is my “is anybody waiting for an answer?” in CLI form. I also wanted to see my agenda.

So I made another small app: google-calendar-tui. It uses the Gmail accounts already registered in GNOME Online Accounts and summarizes my upcoming appointments in the terminal. Read-only. No new OAuth ritual. No extra secret config scattered somewhere weird.

With those two pieces, I modernized clock-tui and added auto-refreshing widget layout support. Now the clock takes the screen the way I wanted, but around it I also get GitHub pending work and Google Calendar appointments.

This is exactly the kind of thing I would never build if it cost me an entire weekend. But with an LLM, it becomes a sequence of small tasks: read the old project, modernize dependencies, run tests, add a widget module, call ghpending, call google-calendar-tui, organize layout, fix bugs, package. It still takes work. But it is supervision and refinement work, not fighting boilerplate.

Tweaking Geary without a fork

Another itch came from GNOME.

Since I wanted to centralize my accounts in GNOME Online Accounts, I started using Geary and GNOME Calendar on the second monitor too. I like the idea: accounts configured once, desktop apps reusing the same infrastructure, no tiny program inventing its own login flow.

The problem is that Geary has a fixed three-column layout. On a normal screen, fine. On a vertical monitor, it gets cramped. The folder column, message list, and email body fight for space. I did not want to maintain a Geary fork just to hide a sidebar. Forking a large GTK app is debt. You blink and spend the rest of your life resolving merge conflicts.

So I made a GTK module: geary-hide-sidebar-module. It injects behavior into Geary at runtime and lets me collapse/expand the sidebar, with a shortcut and auto-collapse for narrow windows. No rebuilding Geary. No fork to maintain. Just a small module with one very specific job.

This is a good lesson: sometimes you do not need to fork the whole application. You can adjust it from the outside. GTK_MODULES exists. Wrappers exist. Config exists. CSS exists. Scripts exist. Not every customization has to become eternal maintenance of somebody else’s code.

Small code got cheap

That is why I keep insisting on this idea of small apps. With current LLMs, it became very easy to implement a specific idea to make your environment fit your needs. No waiting for someone else to have the exact same pain. No searching GitHub for three hours for a tool that does 80% of what you want and 40% of what you don’t want.

You describe the itch, create a repo, ask for a prototype, test it, ask for refactoring, ask for tests, ask for packaging. If it sucks, throw it away. If it works, install it and use it.

I do not let this turn into random junk dumped in ~/bin with no owner. My apps have tests. They have automated builds. Many have GitHub releases, AUR packages, normal installation with yay on Arch. They use XDG paths, so config goes to ~/.config, cache goes to ~/.cache, data goes to ~/.local/share. Organized. Upgradable. Removable. Something another person can clone and contribute to.

Here are all the links in one place:

• ratatui-bubbletea
• ai-usagebar
• clock-tui
• ghpending
• google-calendar-tui
• geary-hide-sidebar-module
• ai-jail
• ai-memory

If you use any of them and it breaks in your setup, open an issue. If you know how to fix it, send a PR. I actually use these tools, so useful bug reports tend to turn into fixes fast.

My practical rule is this: customize your environment without turning everything into duct tape. Build small tools. Test them. Package them. Document them. Let the LLM carry the boring weight and use your brain to decide what is worth keeping.

That is the fun part of programming that had gone missing for a bit. Now it is back.

My short take: AI in open source contributions is here to stay. It will increase, not decrease. Pandora’s box is already open. There is no realistic plan where everyone goes back to programming 100% manually and pretends Claude Code, Codex, OpenCode, Cursor, Gemini CLI, and the rest never existed.

That does not mean every project is obligated to accept AI-assisted contributions. Far from it. The maintainer has the absolute right to run the project however they want. They can accept AI, ban AI, freeze the project, delete the repository and go grow tomatoes. Open source is not mandatory democracy. Whoever maintains decides.

But I also think banning AI is mostly delaying a fight you cannot win. The volume will keep going up. Average quality will wobble. There will be trash, there will be good work, there will be almost-right PRs, there will be hallucinated bug reports. The practical question is not “how do we stop AI?” The practical question is: how do we adapt the process to survive this?

The recent cases

The loudest case right now was rsync 3.4.3. The version shipped on May 20 as a security update, fixing six CVEs. Soon after, users reported regressions, especially in backup flows using daemon mode and incremental transfer options. Rsync is not a toy. It is a backup, deploy, mirror, sysadmin tool. Breaking compatibility there hurts.

Andrew Tridgell, creator of Samba and co-creator of rsync, answered in the post rsync and outrage. He confirmed that he used Claude, with cross-checks from Codex and Gemini, to help rewrite part of the test suite in Python. But he also said the obvious thing a lot of people do not want to hear: he did not type “convert all of this” and go to sleep. He designed the suite, reviewed the work, burned a lot of CI time, and acknowledged that regressions happened in valid but uncommon cases that were covered neither by the existing tests nor by his manual testing.

That is the interesting point: the regression became a discussion about AI, but regression was not born with AI. Regression was born with software.

On the other side we have Zig. The Zig Code of Conduct today has an explicit policy: Strict No LLM / No AI Policy. No LLM-generated content, not code, not prose, not grammar edits, not translation, not brainstorming. Andrew Kelley explained in an interview, summarized by DevClass, that the team considers AI contributions invariably bad, review-time sinks, unteachable, non-deterministic. The line that sums up his position is a good one: the bar he wants is not “works surprisingly well,” it is “uncompromising perfection.”

I disagree with the generalization, but I respect the decision. It is his project. If he wants to keep that space free of LLMs, that is his right. Period.

In the same neighborhood came the Bun discussion. The official post about Bun joining Anthropic says Bun was acquired because Claude Code and other Anthropic coding products depend on it. “If Bun breaks, Claude Code breaks,” in the post’s own words. Meanwhile, the Cosmic piece about the Rust rewrite points to reasons like contributor accessibility, maintainability at scale, and long-term stability. I saw people linking this to Zig’s anti-AI policy, but the source I could verify does not state that causality. What we can safely say is: Bun, a project born in Zig, is moving important parts to Rust, and one stated reason is Rust’s larger contributor base.

Then there is curl. According to Hackaday, Daniel Stenberg suspended curl’s bug bounty program starting February 1, 2026 because the project was flooded with LLM-generated vulnerability reports. Long reports, intimidating, with the shape of a serious exploit, but when an experienced maintainer reads them, they are not vulnerabilities. The PR removing the bounty is on GitHub as curl/curl#20312.

That case is different from a code PR. It is worse. A bad patch you test, compile, read. A fake security report forces someone experienced to spend time proving that the bug does not exist. That is the kind of thankless work that burns maintainers out.

So yes: the problem is real. AI slop exists. It is filling issue trackers, PRs, bug bounties, comments, everything.

Now the part nobody likes: it will not stop.

There is no “back to normal”

I already talked about this in VS Code Is the New Punch Card. The interface changed. First you had to type binary instructions. Then you had to organize punch cards. Then you had to convince the compiler. Then you had to operate editor, terminal, framework, CI, container, cloud, and YAML. Now you have to orchestrate agents.

This does not eliminate engineering. It only changes where the manual work ends.

Some people are treating AI like a passing fad, like the “metaverse” or NFTs. It is not. AI for programming is already past the conference-demo stage. It is inside real workflows. Rsync used it. Bun has Claude Code bots opening PRs. My projects use it. Your contributors will use it, even if you forbid it. If you think you can detect with 100% certainty whether a patch was written with or without AI, good luck with that one.

The maintainer can still set a rule. They can say “if I find out you used AI, I block you.” That may make sense in small communities with their own culture, like Zig. But in open source at large, especially big projects with users all over the world, this turns into compliance theater. The person uses AI, rewrites the text, does not disclose it, and that’s that. What are you going to do? AI detector for code? For crying out loud.

The mistake is thinking you have to review everything alone

The fairest maintainer complaint is simple: there already are not enough people to review human contributions. AI increases volume. More PRs, more issues, more bug reports. The maintainer was already tired, now they are underwater.

I get it. I just do not think the solution is to process the new volume with the old process.

You fight AI with AI.

The first triage has to be done with an LLM. Not to approve automatically. To filter. To summarize. To compare the diff against the stated goal. To point out bad smells. To say “this touches schema, it needs a migration.” To say “this changes public behavior, it needs compatibility tests.” To say “this PR description does not match the code.” That layer alone removes 80% of the grunt work.

The mistake is letting the agent decide alone. The right move is making the agent do the boring investigation, then you decide.

That is how I do it.

My real PR flow

Anyone who followed my AI marathon knows I did not get here after watching two YouTube videos. I spent weeks using agents every day, on real projects, breaking real things, fixing real things. What I am describing here is the workflow that survived that, not LinkedIn theory.

Shameless propaganda: I am happy that my three main AI-related projects are getting contributions almost every day:

• ai-jail, which I already covered in ai-jail: Sandbox for AI Agents.
• ai-memory, which I explained in I Built a Memory System for Coding Agents: ai-memory.
• ai-usagebar, from I Built a Waybar Widget for Omarchy to Monitor LLM Plan Usage: ai-usagebar.

ai-memory in particular became a live experiment. As I write this, GitHub shows 55 closed PRs in the project; through the gh API, 46 were merged and 9 were closed without merge. Thanks to everyone who contributed. Seriously. Djalma, mrpaiva, pedrofjr, CaTeIM, azevedo-luis, brunoomariano, rikelmyso7, abnersajr, and several others. That is a lot of work from a lot of people.

It is also obvious, looking at the style, that most of those PRs were made with AI assistance. And that is not a problem. It would be hypocritical to complain: the entirety of ai-memory was written by AI. I did not open a code editor once to write that thing by hand.

But almost no PR arrives immediately mergeable. That is the point a lot of people still do not understand. “Made with AI” does not mean “blind merge.” It means “the audit begins.”

My prompt for reviewing a PR is more or less this:

check the latest open PR as usual: do not trust the author, audit the whole code thoroughly, make sure it achieves its goal.

Check whether we need to adjust or fix anything before merging: do not accept regressions, do not accept degraded code quality, check whether test coverage is correct.

If it touches build or OS support, check GitHub Actions, CI, clean build, correct wiring, and documentation.

Summarize what the PR does, what you found, and ask me for approval before proceeding.

Notice two things. First: “do not trust the author.” That is not rudeness. It is engineering. The PR description is a hypothesis. The diff is the evidence. Second: “ask me for approval.” The agent investigates, I decide.

When I receive several PRs on the same day, I do this for all of them. After they are all in, I send another prompt:

check today’s commits.

We touched a lot of code, so I need a complete audit of the touched code to make sure we did not add regressions, unnecessary duplication, dead code, or magic values that should become documented constants.

Follow clean code principles, confirm test coverage, and refactor whatever is needed.

If the project is already in use, I add the part many people forget:

this project is already being used. Do not break compatibility.

If we touched database schema or user-file structures, there must be a clean migration on upgrade.

Upgrade must not corrupt data.

This guarantees nothing. But it avoids obvious mistakes.

In ai-memory you can see that pattern in the history. After a big batch of PRs, there are hardening commits from me. One example is 65682dc, “fix(audit): address 5 BLOCKING audit findings from today’s review,” touching OpenAI OAuth, admin API, admission hooks, and the MCP server. Another is the sequence of PRs #65, #68, #70, followed by hardening commits around base path, wikilinks, and strict mode. PR goes in, then audit, then adjustment. That second step is where the difference lives.

In #77, the auto-scope by session/actor change touched a lot: active_project, hooks router, MCP server, stress tests, multi-user tests. More than 3,800 lines added. I am not going to pretend someone reads that manually line by line with the same consistency after the fifth hour. The agent helps map risk. I use my judgment to decide what needs hardening.

Regression happens with or without AI

The rsync case is useful because it exposes a fantasy: the idea that human code was safe and AI code is dangerous.

No. Code is dangerous.

Rust is considered a safe language. And Rust has bugs. Go look at Rust’s issue tracker. Zig wants perfection and has bugs. Curl has bugs. Rsync has bugs. Linux has bugs. SQLite has bugs. My code has bugs. Your code has bugs. There is no magical language that produces bug-free software. There never will be.

This is not pessimism. It is a fundamental limit. In computing, we have known for a long time that there is no perfect general verifier for non-trivial semantic properties of programs. Halting problem, Rice’s theorem, that kind of thing. You can prove a lot in restricted domains. You can use a better type system. You can use Rust to eliminate entire classes of memory-safety bugs. You can use tests, fuzzing, model checking, static analysis. Good. Use all of it.

But “arbitrary software with no bugs” is fantasy.

Humans err because of incomplete context, wrong assumptions, pressure, fatigue, lack of tests, lack of real use. AI errs for the same practical reasons: incomplete context, wrong assumptions, training on bad code, poorly specified goals, weak validation. The difference is scale. AI can produce more trash per minute. It can also produce more fixes per minute if you build the process correctly.

I use it because I use it

Another thing I learned in practice: it is very hard to maintain a project well if you do not use it yourself.

I use ai-memory every day. I use ai-jail every day. I use ai-usagebar every day. I used the Prettify Manga Reader extension in my real reading. That is why I catch bugs automated tests do not catch.

In Prettify, for example, the commits tell the story. 66c6728 added the night filter. Then came b5bcb4d, release 0.2.2, with Kindle Web Reader support, toolbar, shortcuts, and screenshot. Soon after came 0e6b7ee, release 0.2.3, fixing spread pairing so right-to-left reading stayed correct without messing up chronological order. That came from real use. I was reading, noticed strange behavior, asked the LLM to fix it, tested it, released it.

That is the healthy loop: use it, feel the pain, fix it, test again.

In ai-jail, some contributions came from use cases I would not have prioritized on my own. #56 fixed the PKGBUILD on AUR. #55 forwarded OSC 52 clipboard writes through the alt-screen PTY proxy. #51 recognized Grok as a known agent and documented the machine-id privacy mask. These details show up when other people use the tool in setups different from mine.

In ai-usagebar, this is even clearer. #4 added a macOS Keychain fallback for Anthropic credentials. I am on Linux/Omarchy, not macOS. I was not going to find that bug in my daily use. #7 fixed reading a custom credentials_path in the widget. Same story: a user with a different config from mine. This is where open source shines: someone scratches their own itch and improves the project for everyone else.

But notice: when I cannot test manually, like macOS and Windows, I depend more on CI. GitHub Actions runs macOS, Windows, Linux. It does not replace real use, but it reduces risk. And when someone who uses that environment opens an issue or PR, that is gold.

Manual testing is still the last line of defense. If you give it up, you are introducing bugs by definition. Automated tests catch what you remembered to specify. Real use catches what you did not even know you needed to specify.

After merging a large set, my final flow is usually:

now run bin/deploy to my home server and test it online.

Check health, check whether it still works as before.

Again: it guarantees nothing. But it avoids breaking the obvious.

There is no silver bullet

I do not think every project should accept AI PRs. I also do not think every project should ban them. There is no universal rule.

If you are a solo maintainer of a critical library, with no time, no decent CI, no energy to deal with an avalanche of bad PRs, banning AI-assisted contribution may be the right decision for now. Better that than accepting junk and breaking users.

If you maintain a small community and want to teach human contributors, as Zig argues, an anti-AI policy makes sense inside that culture. You are optimizing for contributor formation, not patch throughput.

But if you maintain a project that already gets high volume, that already has CI, that already has tests, that already has users, I think adaptation is inevitable. You will need automated triage. You will need an agent reviewing PRs. You will need a bot summarizing issues. You will need a tool that says “this looks like a hallucinated vulnerability report.”

AI is imperfect and scales fast. That is exactly why the process has to change.

My conclusion

AI slop is real. It will get worse before it gets better. There will be garbage PRs. There will be fake security reports. There will be regressions blamed on AI that would have happened with humans too. There will be angry maintainers. There will be users yelling. Normal.

But the direction does not change.

AI-assisted code is here to stay. The percentage of code touched by agents will keep rising. Banning it can work locally, for a while, in one specific community. Across the industry, it is a lost war.

The pragmatic path is to make AI work for us. Use AI for triage. Use AI for audits. Use AI to compare diffs. Use AI to find regressions. Use AI to write tests that fail before and pass after. Use AI to do the boring work that wears humans down.

And keep the human decision where it matters.

I have said this several times and I will repeat it: AI is a mirror.

If you are sloppy, it accelerates your sloppiness. Your code becomes industrialized AI slop.

If you are a real engineer, it amplifies your engineering. You keep demanding tests, CI, compatibility, migrations, review, clean code, deploy, manual testing. You just do it 10 times faster.

And for companies: if you are thinking, “great, now I save money because I do not need to hire as many programmers,” I get it. Up to a point. But if you are putting AI into the workflow, then you must strengthen QA. More tests, more review, more validation process, more good people thinking about quality. Skip that and you are screwed. You will trade development cost for production bugs, rework, incidents, and angry customers.

There is no going back to the 100% manual world. Better to stop wasting energy trying to close Pandora’s box and start building a decent process around what came out of it.

And here’s the part nobody mentions when they say “I built a project with AI”: generating the code is the easy part. The hard part, the thing that separates a repo that’s just a pile of code from an actual open source project, is everything that comes after git init.

I have a strong opinion about this, so let me just plant the flag: no open source project is ready to be published without three things. In order of importance:

1. Installation surface. The new user has to be able to install and try the tool with the least friction possible. One command, ideally.
2. Tests and automated CI. So contributions are easier and there’s common ground on what’s minimally acceptable to land in the project.
3. Documentation. The short, easy-to-read version (the README) and a more detailed set in docs/, so new contributors understand the architectural decisions.

Without those three, the way I see it, the project isn’t ready. It can have the most brilliant code on earth inside, doesn’t matter. If a stranger can’t install it, can’t trust that whatever they touch won’t break everything, and can’t understand why things are the way they are, then you don’t have an open source project. You have a public dead archive.

And there’s a bonus that became an essential part of my workflow: when all my projects follow the same pattern, I can just tell Claude Code or Codex “run the deploy” or “cut a release,” and they can do it. Because the structure is predictable. bin/deploy does the same thing in every project. The release comes out of a tag. The agent doesn’t have to guess anything. Standardization is what makes the automation trustworthy. It looks like fussiness from an organized person, but it’s the prerequisite for me to trust, eyes closed, whatever the agent is about to run.

Let me break down the three pillars and show the minimum setup I actually use.

Pillar 1: The installation surface

This is the most important one and the most neglected. People spend weeks tuning the internal algorithm and then ship a README that says “clone the repo and run cargo build --release.” So the guy who was curious enough to try it needs to have Rust installed, wait ten minutes for it to compile, and pray no system lib is missing. You just lost 90% of your potential users.

The ideal is to offer several paths and let the user pick the one that fits their environment. Look at the install header for ai-jail, my champion of options:

# Homebrew (macOS or Linux)
brew tap akitaonrails/tap && brew install ai-jail

# AUR (Arch Linux) - prebuilt binary
yay -S ai-jail-bin

# cargo (any platform with Rust)
cargo install ai-jail

# mise
mise use -g github:akitaonrails/ai-jail

# Direct binary download
curl -fsSL https://github.com/akitaonrails/ai-jail/releases/latest/download/ai-jail-linux-x86_64.tar.gz | tar xz

Five paths. The Arch user runs yay. The macOS one runs brew. The Rust dev runs cargo install. Whoever uses mise to manage versions pulls it through mise. And whoever just wants the binary downloads the tarball straight from the release. Everyone grabs what they’re already used to, nobody’s forced to install a whole toolchain just to kick the tires.

The secret: compile once, repackage many

The gotcha that scares you at first is thinking each package format needs its own build. It doesn’t. The trick is to compile the binary once per architecture, then repackage that same binary into every format.

In my Rust pipeline, the build job produces a tarball with the finished binary and its sha256. The packaging steps that follow (Docker, AUR, Homebrew) download that already-compiled tarball instead of recompiling. It cuts CI time, guarantees the byte that goes to AUR is exactly the one that goes to Docker, and kills off that whole class of “works in one format, breaks in the other” bug.

# Docker job reusing the already-compiled binary
docker-amd64:
  needs: build-linux
  steps:
    - uses: actions/download-artifact@v4
      with:
        name: ai-memory-linux-x86_64
        path: artifacts
    - name: Desempacota o binário pré-compilado
      run: tar -xzf artifacts/ai-memory-linux-x86_64.tar.gz -C dist/docker/
    - uses: docker/build-push-action@v6
      with:
        target: runtime-prebuilt-amd64  # inject the binary, don't recompile

The AUR job does the same thing: download the tarball, compute the sha256, inject it into the PKGBUILD:

X86_SHA=$(awk '{print $1}' artifacts/ai-usagebar-linux-x86_64.tar.gz.sha256)
sed -i "s/^sha256sums_x86_64=.*/sha256sums_x86_64=('$X86_SHA')/" packaging/aur/PKGBUILD-bin

That’s the core idea. The binary is the real artifact. RPM, DEB, AppImage, AUR, Homebrew tarball, Docker image, all of it is just wrapping around the same binary.

The two snippets above are excerpts. If you want to see the whole thing running, the full build-once-reuse flow (binary compiled once, reused across the Docker and AUR jobs) lives in ai-memory’s release.yml, and the sha256 injection into the PKGBUILD is in ai-usagebar’s release.yml.

The menu of formats

Every platform is its own world. Here’s the minimum worth knowing:

Linux is the most fragmented. The options, from simplest to most work:

• Tarball (.tar.gz): the lowest common denominator. Works on any distro, just unpack it and drop it in PATH. Always offer this one.
• AUR (Arch): two packages, the -bin (prebuilt binary, installs in seconds) and the source one (compiles on the user’s machine). I publish both with the KSXGitHub/github-actions-deploy-aur action. The -bin is what everybody uses.
• AppImage: a single executable file that carries all its dependencies inside. Good for desktop apps. Frank Sherlock, which is Tauri, builds the AppImage right in the build and I still GPG-sign it afterward (the signing step is in its release.yml). For a simple binary you can use appimagetool.
• RPM and DEB: for Fedora/openSUSE and Debian/Ubuntu. The tool that saves your life here is nfpm, which generates both from a single declarative nfpm.yaml, no need to learn the guts of rpmbuild or dpkg-deb. It takes the already-compiled binary and spits out both packages.

macOS has two targets: Apple Silicon (aarch64-apple-darwin) and Intel (x86_64-apple-darwin). You either compile them separately or build a universal binary with lipo. And here lives the platform’s biggest headache: signing and notarization. Without it, macOS Gatekeeper refuses to open your app. The flow is to decode the P12 certificate, import it into a temporary keychain, sign with codesign --options runtime --timestamp, and notarize:

codesign --sign "$APPLE_SIGNING_IDENTITY" --options runtime --timestamp ./meu-binario
ditto -c -k meu-binario notarize.zip
xcrun notarytool submit notarize.zip \
  --apple-id "$APPLE_ID" --password "$APPLE_PASSWORD" \
  --team-id "$APPLE_TEAM_ID" --wait

This requires a paid Apple Developer account. It’s annoying, but it’s the price of not throwing an “app is damaged” error in your user’s face. The whole signing-and-notarization job, with the temporary-keychain dance, is in ai-jail’s release.yml.

Windows is the easiest to build (x86_64-pc-windows-msvc) and the thorniest to sign. A Windows code signing certificate is expensive and bureaucratic, so I, honestly, don’t sign. I accept that SmartScreen will throw a warning on first run and I make that clear in the README. For a personal open source project, that’s good enough.

Rust crates (cargo publish): if it’s a Rust library or CLI, publishing to crates.io gives you cargo install for free. One line in the pipeline. Tip: make it idempotent, because re-running on an already-published tag errors out. I grep the output for “already exists” so it doesn’t blow up the whole release over that.

Homebrew: the clean way is to keep your own tap (akitaonrails/homebrew-tap). The pipeline updates the formula with the new URL and the new sha256 on every release. The user runs brew tap once and after that it’s just brew upgrade.

mise: mise can install straight from GitHub releases without you configuring anything on your end, as long as your tarballs follow a platform-name convention. You get this path basically for free just by naming your releases well.

Notice a detail: AUR, Homebrew, mise, and the direct download all consume the same release tarball. You publish the binaries once, and four different package managers know how to fend for themselves. That’s why “compile once, repackage many” is the golden rule.

Pillar 2: GitHub Actions, tag-based releases, and the changelog

The second thing that makes an open source project serious is CI. Forget the “build passing” badge on the README, the value is in the common ground it creates: when someone sends a pull request, CI runs the tests, the linter, and the security scanner, and you know right away whether that contribution breaks anything. Without it, every PR turns into a tiresome manual negotiation.

On my Rust projects CI runs cargo fmt --check, cargo clippy -D warnings, cargo test, and cargo audit. On the Rails projects it’s rubocop, brakeman (security scanner), bundler-audit, and the Minitest suite. FrankMD alone has over 1,800 tests between Ruby and JavaScript. Frank Sherlock clears 300 tests in Rust plus 300 on the frontend. That safety net is what lets me accept a stranger’s PR without sweating.

PR review with an LLM

The tests and CI are the bottom net. Above it there’s a layer that became central to my workflow: using the LLM itself to review the pull requests. Opus and GPT are absurdly good at code review and quality refactoring. Better than me on consistency, because they don’t get tired and they don’t skim over 200 lines just because it’s the fifth review of the day.

I have two prompts I use all the time. The first, for a specific PR that just landed:

look at the open PR on github. don’t trust the author’s description. audit the code thoroughly to see if it actually makes sense. make sure there are no regressions and no drop in code quality. make sure test coverage is adequate. then tell me what you think we should do.

Notice the “don’t trust the author’s description.” That’s deliberate. A PR description tells you what the person thought they did, and it doesn’t always match what they actually did. The LLM has to read the real code, not the summary.

The second prompt is for after a long coding session or a bunch of PRs merged at once:

we touched a lot of code. audit the code those PRs changed, look for dead code, unnecessary duplication, magic hardcoded values that should be constants and/or better documented, missing test coverage, aim for clean code principles, then check whether the documentation was properly updated.

With the verdict in hand, I decide. For an incomplete PR, what I do depends on the size and my priority at that moment. If it’s something small, I fix it myself right in the PR with an amend, reply explaining what I changed, and then merge and close. When I can merge but can’t fix beforehand, I merge and immediately drop a follow-up fix commit. And when it’s a big change, I ask the LLM to reply to the PR explaining why we’re not merging, with the right direction on what needs to be done.

That’s how I closed almost 40 PRs and 20 issues on ai-memory alone, in a couple of days. That volume doesn’t happen by hand, and it also can’t happen on autopilot.

And this is the point I keep hammering: none of this is blind. I’m piloting the LLM toward those goals the whole time. It does the audit, puts the suggestions on the table, and even writes the text of the reply, but the one who decides to merge, fix, or reject is me. The LLM is the tireless reviewer; I’m the one who signs off.

The tag-based trigger

The release part is separate from CI. While CI runs on every push and PR, the release fires only when you push a version tag:

on:
  push:
    tags:
      - 'v*.*.*'   # dispara em v1.2.3, v0.5.0, etc.
  workflow_dispatch: # permite disparar manualmente também

The flow for cutting a version becomes this:

git tag v0.5.0
git push origin v0.5.0

And that’s it. GitHub Actions notices the tag, fires the release workflow, compiles for the targets, packages everything, signs whatever needs signing, creates the GitHub Release, and publishes to the package managers. I don’t touch anything else. In fact that’s literally what I tell Claude Code: “cut v0.5.0.” It runs cargo set-version, updates the CHANGELOG, commits, creates the tag, pushes, and the rest is the pipeline.

The Rust build matrix compiles each target on its native platform:

strategy:
  matrix:
    include:
      - os: ubuntu-22.04
        target: x86_64-unknown-linux-gnu
      - os: ubuntu-22.04-arm
        target: aarch64-unknown-linux-gnu
      - os: macos-latest
        target: aarch64-apple-darwin
      - os: windows-latest
        target: x86_64-pc-windows-msvc

A cross-compilation gotcha: if you compile ARM inside an x86 machine (via cross), you can’t run the tests for that binary right there, because the architecture doesn’t match. The fix is to run tests only on the native target and cross-compile the rest without testing. ai-usagebar does exactly that, x86 native and ARM via cross, in the matrix of its release.yml. And always use a compile cache: Swatinem/rust-cache easily cuts build time in half.

Release notes and the changelog matter

This is where a lot of people slack off, and they shouldn’t. When you cut a release, the person thinking about upgrading wants to know what changed. “v0.5.0” says nothing. A changelog says something.

I keep a CHANGELOG.md in the Keep a Changelog format, one section per version. And the pipeline automatically extracts the current version’s section to paste into the GitHub Release body. A simple awk handles it:

awk -v ver="$VERSION" '
  BEGIN { hdr = "## [" ver "]" }
  index($0, hdr) == 1 { flag=1; next }
  flag && index($0, "## [") == 1 { exit }
  flag { print }
' CHANGELOG.md > changelog_section.md

That awk is the same one that runs on the ai-usagebar release (again in its release.yml, which is my most polished one on this front). Then, after the changelog, I append the install instructions and the sha256 checksums for each artifact. The result is a GitHub Release that explains itself: what changed, how to install it, and how to verify the integrity of the download. The user reads it and decides whether to upgrade. That’s the kind of care that makes a stranger trust your project.

Pillar 3: Real deployment, no fuss

The projects that run as a service (the Rails ones, mainly) have to go somewhere. And here I go against the hype. No Kubernetes. No Kamal. No three-stage deploy pipeline with manual approval.

I have a home server. A Minisforum MS-S1 Max running openSUSE MicroOS that I migrated recently, with a Gitea acting as a private Docker registry on port 3007. For a solo developer with a simple home server, that’s more than enough. All that cluster-orchestration ceremony is solving a problem I don’t have.

The whole deploy fits in a single bin/deploy. It does three things: builds the image, pushes it to the registry, and SSHes into the server to bring up the new version:

#!/usr/bin/env bash
set -euo pipefail

# Config comes from a .gitignored file, outside the repo
source "$(dirname "$0")/../config/deploy.env"

IMAGE="${REGISTRY_HOST}:${REGISTRY_PORT}/akitaonrails/frank_fbi:latest"

echo "==> Buildando a imagem..."
docker build -t "$IMAGE" .

echo "==> Empurrando pro registry..."
docker push "$IMAGE"

echo "==> Subindo no servidor..."
ssh "${DEPLOY_USER}@${DEPLOY_HOST}" \
  "cd ${REMOTE_DIR} && \
   docker compose pull && \
   docker compose down --remove-orphans && \
   docker compose up -d"

That’s it. build, push, ssh with pull, down, up. Four commands on the remote server, chained in a single SSH. No agent running over there, no webhook, no control panel. The server has a docker-compose.production.yml pointing at the :latest image from the registry, and the pull brings the new version down.

Notice the sensitive data lives in a config/deploy.env that doesn’t go into Git. The repo only carries the config/deploy.env.example, with the structure and fake values. This “versioned example, real one ignored” pattern repeats in every project of mine, and it’s what lets the project be public without leaking the host, user, or path of my server.

The image itself comes from a multi-stage Dockerfile. The build stage installs the compilation tools, builds everything, and the final stage copies only the result into a lean image, running as a non-root user. The production compose swaps build: for image:, points the volumes at the server’s persistent paths (/var/opt/docker/...), and uses restart: always to bring everything back up if the server reboots.

And again, the beauty of standardization: since every project of mine has this same bin/deploy, I can tell Claude Code “deploy Frank FBI” and it knows exactly what to run. I don’t have to remember a single command. The tool is the executable documentation of the process.

The lesson: nobody cares about your stack

Now the part I most wanted to write, and the one worth more than all the YAML snippets above.

Most people, when they go to present a project, focus everything on the technology. “Check out my brand-new vector database.” “Check out my last-gen reactive framework.” “I used such-and-such microservices architecture.” And they fill the top of the README with that: the dependency list, the component diagram, the stack.

Nobody cares.

Seriously. The user who lands on your README doesn’t want to know which database you used. They want to know what problem this solves for them. Implementation detail doesn’t belong at the top of the README. It belongs in docs/, for whoever’s going to contribute. In the README, what matters is the use case.

Look at the difference. “MCP server in Rust with FTS5 and optional LLM consolidation” says nothing to anybody. Now “long-term memory shared across Claude Code, Codex, and Cursor, with handoff between sessions” — that one the guy gets instantly, because it’s the pain he has. Both describe ai-memory. One talks about technology, the other talks about the problem it solves.

The use case is the single most important thing about the whole project. Before writing a line of code, the right question is “what problem does this solve, and for whom?” If you can’t answer that in one sentence, you’re building a solution looking for a problem. And a solution looking for a problem is, in practice, a solution that solves nothing. Doesn’t matter how elegant the code is on the inside.

The UX layer, the surface the user touches, is worth far more than the internal engineering. A project with mediocre technology that’s trivial to install, that clearly states what problem it solves, and that has honest documentation, goes further than a brilliant project nobody can run. Every time.

So the minimum, the real minimum for an open source project, is this: easy install, CI that gives you confidence, documentation that starts from the problem. The pretty algorithm comes way down the priority list. The three pillars of this post exist to serve one thing, which is the experience of whoever shows up from outside. Get that right first. The rest is implementation detail.

The Problem

Before, to contribute to the blog you had to:

1. Install Hugo Extended
2. Install Go
3. Install Ruby
4. Set up all the dependencies
5. Generate the post index manually

This created barriers for new contributors and could cause conflicts with other installations on the system. A nightmare.

The Solution: Docker

Now all you need is Docker and Docker Compose. Everything else runs inside isolated containers.

Quick Setup

# Clone the repository
git clone https://github.com/akitaonrails/akitaonrails.github.io.git
cd akitaonrails.github.io

# Start the environment
./scripts/dev.sh start

# Open the blog
open http://localhost:1313

Done! The blog is running and you can start contributing.

Useful Commands

The project includes scripts that make development easier:

# See all available commands
./scripts/dev.sh help

# Create a new post
./scripts/dev.sh new-post "Título do Meu Post"

# View server logs
./scripts/dev.sh logs

# Generate the post index
./scripts/dev.sh generate-index

# Stop the environment
./scripts/dev.sh stop

Creating a Post

Creating a new post is dead simple:

./scripts/dev.sh new-post "Como Contribuir no Blog do AkitaOnRails"

The script automatically:

• Creates the directory structure with the current date
• Generates an index.md file with basic front matter
• The Hugo server reloads automatically

Structure of a Post

The created file will have this structure:

---
title: "Título do Post"
date: "2025-08-29"
draft: false
description: "Descrição do post"
tags: [tag1, tag2]
categories: [categoria]
---

Conteúdo do post aqui...

Advantages of Docker

For Contributors

• Fast setup: Docker is the only requirement
• Isolated environment: Stays out of the way of your local system
• Hot reload: Changes show up automatically
• Reproducible: Works the same way for everyone

For the Project

• Fewer issues: Consistent environment
• More contributors: Lower barrier to entry
• Maintenance: Easy to update dependencies

How It Works

The Docker environment includes:

• Hugo Extended: Static site generator
• Go: For Hugo modules
• Ruby: For the index generation script
• Volumes: For hot reload of files

The docker-compose.yml maps the local directories into the container, so when you edit a file, Hugo detects the change and reloads automatically.

Local Development (Alternative)

If you prefer to skip Docker, you can still install everything locally:

# Generate the index
cd content && ruby generate_index.rb

# Run the server
hugo server --logLevel debug --disableFastRender -p 1313

But Docker is way more practical!

Next Steps

1. Test the environment: Run ./scripts/dev.sh start
2. Create a post: Use ./scripts/dev.sh new-post
3. Explore the code: See how to customize layouts
4. Contribute: Open a Pull Request

Tip: The Docker environment automatically saves your changes and reloads the server. Just edit the files and watch the changes in real time! 🚀

My impressions stem from very specific circumstances, so this is not to be read as a general recommendation for every situation. For example, I didn’t review GitLab’s hosted options, which may be more compatible with circumstances different than mine.

In my case, the move to GitLab was part of an internal company strategy to have more control over our own data. In that strategy we also moved from using Slack to Mattermost, and from using Pivotal Tracker to my own open source alternative called Central, among other things.

Before the migration, I had dozens of active projects over GitHub and lots of archived ones at Bitbucket. I’m the kind that hates to lose data, so I keep redundant backups and try to never erase anything.

I moved almost everything over to my own GitLab server and this is almost 200 repositories, spread in 4 groups, with almost 80 active users. This accounts for more than 13,500 notes and over 5,200 Merge Requests already, and over 2,500 builds in the CI, and the internal Sidekiq controlling everything has over 51,000 jobs processed.

In the last 3 months since the migration, I am paying a Digital Ocean bill of around $140 every month for the exact infrastructure I described in the previous article, with a separated box for the GitLab Core, the CI Runner, the CI Docker Registry Mirror, the CI Cache server and disposable machines for parallel builds, controlled by the Runner.

Although the reduction in cost is welcome, the whole endeavor was not done because of it. I could easily pay double or triple just for the convenience, but the underlying strategy is more important in this case.

My company has over 60 developers, working from our own offices in 6 different cities in Brazil (no freelancers and no home-office), communicating daily over Mattermost, Code Reviewing through GitLab’s Merge Requests, having immediate automated tests feedback from GitLab CI, and project management through our own Central application.

The only piece that is currently missing is a good static code analysis tool. We heavily rely on Code Climate, which I strongly believe is one of the best out there from our own experience.

I was about to start an endeavor to build a simplified OSS version to integrate into GitLab CI’s, but Bryan Helmkamp recently announced that they would release their own “Community Edition” version of Code Climate in the next few months.

This is exactly the missing piece in my stack, and it will make my strategy move faster for next year.

Hybrid-SaaS Era

In the past 5 to 10 years there was a fast move towards 3rd party “micro-services” structure. And this is really great as it allowed many small companies or even independent developers to tap into technology that made them not only move faster, but with increasingly more quality in their delivery.

It’s now super easy to have top-notch upload and storage service through tools like Cloudinary.

Also very easy to have top-notch relational database, with replication and scalability, such as Heroku Postgres or AWS RDS.

Project management as a service with Pivotal Tracker, Trello.

Communication as a service with Slack, Hangout, etc.

Knowledge Management as a service with GitHub, Bitbucket, etc.

So now many tech companies are a mashup of several different 3rd party services.

My small beef is that our entire knowledge, experience, portfolio is spread across a dozen or more opaque services, completely out of our control and depending on each company’s (or their investors) whim.

Don’t get me wrong, I am not against using those services, on the contrary. I use several of them and I will continue to use many of them for the foreseeable future. Some endeavors would not even be possible without the efficiency of this sample of a technology-based free market.

But every now and then you reach a tipping point where it becomes important to have more control over your own data, your own identity. Not only for pure ownership but also to be able to use this data with better intent.

And I believe that at that point we should have an option that doesn’t cost a couple of limbs to replicate.

Before an option such as GitLab, we were either limited to choose between walled-gardens such as GitHub or Bitbucket or you could invest a ton of resources trying to use small open sourced components to try to build your own. With GitLab we now have the option to make a smooth transition to its hosted option, so we don’t have to deal with infrastructure maintenance or we can choose to have full control. And the users will not suffer in the process.

Which is why I believe that the best SaaS to endure the next decade will start to go into Hybrid-mode: having a commercial, usually “cheaper”, hosted option, and a DIY (do-it-yourself) OSS version.

GitLab is like that. Mattermost is like that. Now Code Climate is getting like that.

In that option, companies like GitLab have a win-win situation. Many more people and companies can contribute towards making a mature and robust platform that everybody enjoys using, and at the same time, each participant can extend it to their own particular plans. GitLab can have a sustainable business model serving the long tail of companies and developers that want a reasonably affordable hosted service while the top 20% can pursue more specific endeavors using the same technology.

That way we remove the discussion of confidentiality, the way companies treat our data, and we move forward into more productive actions such as building a tool that benefits both the external public and each other’s internal plans.

Walled gardens are here to stay. Releasing integration — while opaque — public APIs is not enough. It’s very exciting to see those new options arising to fill this gap. The OSS environment along with a sustainable business model makes sense. And I hope to continue to see more and more competitors to closed services following the Hybrid model in the near future.

Why go through the trouble to install, maintain and tweak open sourced alternatives to well-established hosted (albeit opaque) services? I believe it’s more than a discussion over convenience, maintenance and cutting costs. We should start small, less risky, but as we grow we should be able to take control back. But we usually can’t get out of walled gardens without a significant - and sometimes impossible - investment in reinventing the wheel. We always had the small open sourced components that those services are built on, but to go from those small components to a full-featured system, it’s an unrealistic path.

With this possible trend of post-SaaS, or Hybrid-SaaS as I call it, we may have just gained the missing link to go from just convenience to full control without the inherent costs and risks chasm.

“The foundation of that is the open source world: the biggest capitalist experiment in software and a living example of what a Laissez-faire Free Market looks like. The best place to maintain and improve technology commodities.”

The confusion comes from the word “free”. Because of the freedom principles of Free Software, a lot of people associate open source with one big “socialist” experiment. My thesis is the opposite: free software is the most capitalist thing in software. No government regulates it, no agency protects bad projects, every exchange is voluntary, and competition decides who survives. No sector of the real economy works like that; the closest historical period was late 19th century America, before the Federal Reserve and the federal income tax.

Matt Asay wrote on CNET, in “Open source: It’s about capitalism, not freebies”:

“The secret is to use open source as a means to an end, not the end itself. Open source is a means to cheap distribution, a way to get software into the hands of would-be buyers at little to no cost. It’s a way to make the software experience social and less risky, because users can try before they buy and because they can tailor (or pay someone else to tailor) software to their needs for a lower cost than proprietary software affords.”

And he was even more blunt in “Sorry, socialists: Open source is a capitalist’s game”:

“[Sarah] Grey writes that ’there are alternatives to capitalism’. She’s right. Unfortunately, open source isn’t one of them. Open source is the essence of Free Market Capitalism.”

Definitions, so nobody fights a strawman

First, the terms I’m using. Capitalism is private ownership of the means of production, with voluntary exchanges between the owners of that property. A Free Market is those exchanges carried out with no coercion and no regulator: supply, demand, and prices stay in the hands of the participants.

Socialism, in the classical sense, is state or collective ownership of the means of production. Public healthcare and free education in a market economy are welfare policies, not socialism. The target of this text is the model where the State owns production.

With these definitions, defending classical socialism and defending individual liberty are opposite positions: the first requires subordinating everyone’s property and choices to a central authority.

Free software is private property under a license

Open source code has an owner, always. Copyright belongs to the authors, and using, copying, or modifying that code is only possible because the owner granted a license. Without a license, nobody has any right over someone else’s code, as Jeff Atwood pointed out in “Pick a License, Any License”:

“Because I did not explicitly indicate a license, I declared an implicit copyright without explaining how others could use my code. Since the code is unlicensed, I could theoretically assert copyright at any time and demand that people stop using my code. Experienced developers won’t touch unlicensed code because they have no legal right to use it.”

There’s a practical test for this property: the owner can pull the code out of circulation whenever they want. In March 2016, Azer Koçulu unpublished his packages from npm, including the tiny left-pad, after a name dispute with the Kik app. Thousands of builds broke that same day, as Ars Technica reported. The source code stayed on GitHub; what he removed was the distribution from the registry.

Agreeing with Koçulu or not is irrelevant. The package was his property, and the decision to remove it was his. The interesting part came after: nobody got arrested, no regulator stepped in. npm restored the broken package and changed its unpublish policy. The market absorbed the shock and grew antibodies, without taking away anyone’s right to walk out.

The Ruby community lived through a smaller version of this in 2009, when _why deleted his projects and vanished, as I wrote here.

When the disagreement is internal, the exit mechanism is the fork: whoever disagrees clones the project and competes with the original. That’s what happened with io.js, born as a fork of Node.js in 2014 and merged back in 2015 under the newly created Node.js Foundation, once negotiation made sense. History has plenty of thriving forks: WebKit from KHTML, LibreOffice from OpenOffice.org, MariaDB from MySQL, X.Org from XFree86. And there are derivatives that outgrew their origins, like Ubuntu from Debian.

A fork is voting with your feet. It’s expensive, because it means maintaining an entire project, and that’s exactly why it only thrives when the motivation is real.

Competition implies the right to fail

In a market with no regulator, nobody keeps a bad project artificially alive. For every PostgreSQL out there, dozens of databases tried and died. For every relevant Linux distro, hundreds became footnotes. That’s a sign of health: selection is working.

The justice of this process is blind. Code doesn’t carry its author’s biography, and the market hands out no medals for good intentions. A project survives if it convinces users and contributors of its technical merit, and dies if it doesn’t.

Opening the code, by the way, saves no one. Nokia finished open-sourcing Symbian in 2010, when the platform was already losing ground to the iPhone and Android. The gesture changed nothing: too little, too late.

I compared this process to natural selection in an old screencast (in Portuguese). The software that adapts best to the demands of its environment is the one that reproduces the most, as users and contributors. The graveyard of dead projects proves selection exists and works.

And the landscape shifts all the time. Apache HTTP ceded ground to NGINX. Firefox lost a huge slice to Chrome. Perl ceded to Python and to newer languages like Go. MySQL lost prestige among developers to PostgreSQL, faced the NoSQL wave, and still gained a competing fork, MariaDB, after the Oracle acquisition. None of these projects had squatters’ rights to the throne.

The programmer pays to participate

The free software market has a curious inversion of values. At a company, the programmer gets paid money to write proprietary code. In a well-known free project, it’s the programmer who “pays”, with their time and skill, to get code accepted. In return they get reputation, learning, portfolio, and yes, a bit of vanity. It’s a voluntary exchange that benefits both sides, like any other.

“Price” here isn’t measured only in money. Value is anything with supply and demand, and competition sets the price. The currency of this market is technical competence demonstrated in public.

That has a hard consequence: convincing others is part of the game. If your idea has value and still nobody adopts it, the most likely explanation is the idea or how you presented it, not the audience’s stupidity. Blaming the audience is the fastest way to devalue your own cause.

The paradox of “socialist” free software

Picture the opposite model: the software world under classical socialism, with production controlled by a central authority.

Without individual ownership of projects, competition ends. A bad project that serves the controllers’ agenda stays alive, even when a technically superior alternative exists. Choice leaves the hands of the users and moves to the hands of the controllers. There would be no left-pad accidents, and the price of that would be a huge catalog of derelict software nobody wants to use.

Without the individual benefit of exchange, volunteering ends. No competent programmer would donate their best hours without reputation, learning, or freedom in return. And if contribution becomes a mandatory quota decreed in the name of the “social good”, everyone will do the bare minimum to fill the quota. Soviet production worked exactly like that in pretty much every sector, with the results we all know.

Without competition, innovation ends. Innovation is born from an individual’s will to solve their own problem their own way. Eric Raymond opened “The Cathedral and the Bazaar” with that idea:

“Every good work of software starts by scratching a developer’s personal itch.”

Innovation is also transgressive, because it makes entire professions obsolete. Travel agencies nearly vanished once buying tickets online became trivial. Video rental stores died with streaming. Uber squeezed cab drivers, Airbnb squeezed hotels. Whoever stayed stuck in the old model suffered, and the world moved on.

Software was the same. The GNU Hurd folks didn’t celebrate when Linux exploded. Nokia found no humor in Android. MySQL doesn’t root for PostgreSQL. Whoever resists the market’s dynamics gets left behind. Harsh, and absolutely fair.

The dystopia of the protected monopoly

Proprietary software can be good or bad; the problem shows up when it becomes a protected monopoly. 1990s Microsoft was a de facto monopoly. We can argue forever about whether the Department of Justice ruling was fair, but the decisive blow to the monopoly came from the market: free software, with GNU and Linux, and then the commercial internet, which took the platform monopoly away from Windows.

Imagine an alternate future where Microsoft convinces the US government that Windows is essential to national security and deserves permanent protection. Everything would have stopped. To this day we’d be using a 100 MHz Pentium running some Windows 98 derivative, on dial-up, because “nobody needs more than that”.

That’s the logic of handing the market’s decisions to a central authority: don’t invent email, it will hurt the mail carriers; don’t build websites, it will hurt the printing plants; don’t create free software, it will hurt the government’s programmers. Every dictator uses the same speech, “for the good of the people”, and every speech of “for the good of the people, whatever the means” ends in the same place.

Tyranny and the end of free software

The worst possible case for a free project starts like this. A developer builds a piece of software to solve a problem and opens the code. For twenty years, hundreds of people use it and contribute.

Then a cause comes along, any cause, and someone appoints themselves its representative. Through social pressure and propaganda, the maintainers become pariahs. The trade press amplifies it, because controversy attracts readers. The code stops being the subject: what counts now is each contributor’s personal opinions, appearance, and past.

From that point on, participating in the project becomes a risk. Contributing pays no value anymore; all it pays is exposure. One by one, the people who actually wrote code walk away, and the project withers. It’s a perverse way of seizing a property and destroying its value without formally confiscating anything.

Ayn Rand dramatized exactly this mechanism in Howard Roark’s trial in “The Fountainhead”, and I wrote about it in 2011:

“I came here to say that I do not recognize anyone’s right to one minute of my life. Nor to any part of my energy. Nor to any achievement of mine. No matter who makes the claim!”

That’s the warning. A political layer on top of a free project destroys the market that sustained it.

Conclusion

None of this condemns anyone who contributes out of social motivation. Whoever trades their code for the feeling of helping is making a voluntary exchange like any other, and outside software that has a name: donation and volunteer work. The trouble starts when someone decides that other people’s property must serve the cause they picked.

Solving the world’s problems is much harder than arguing about them. Bill Gates delivered that message in 2000, pushing back on the hype that PCs would end poverty:

“Fine, go to those Bangalore Infosys centers, but just go and try those guys three miles outside, and look at the people who are living without a toilet, without running water… The world is not flat and PCs are not, in the hierarchy of human needs, in the first five rungs.”

Programmers, from any social class, have internet and resources to spare, enough to spend the day on social media debating how to save the world. The people actually working on those problems are outside that circuit, doing instead of talking.

I’ll close with a real story someone told me, names removed:

A: Man, nobody gives my [minority] a chance.

B: Why don’t you help me fix these issues in this open source project? Then you can give talks about it.

(A vanishes. B waits, gets tired, and calls C, who fixes the issues and gets the speaking slot.)

A: See, B? You’re one of the oppressors who won’t give people like me a shot, and you’d rather hand the opportunity to C.

And a personal note to wrap up. People label me an “Ayn Rand follower”, and they’re wrong: Rand merely put in writing, before me, what I already thought and practiced. Same goes for Bastiat, Friedman, Hayek, or Menger. They’re references, and references are not owners. Judging an idea by its author instead of judging the argument on its merits is the definition of ad hominem, and I don’t respond well to fallacies.

If you’re an experienced programmer, you don’t need me to tell you this. But if the recent news rattled you, maybe what I have to say will give you some perspective.

First, I want to share a few other articles I read over the last few days:

• My Next Chapter: the statement by Mike Perham, one of the best-known Rubyists of this generation and creator of the ubiquitous, excellent Sidekiq. He’s not abandoning the project; he’s building a new product, and that product doesn’t involve Ruby.

• Saying Goodbye To Python: here it was the Pythonista Ian Bicking, announcing he was trading Python for JavaScript, riding the current wave. Worth understanding that today’s JavaScript bubble doesn’t “require” you to “leave” anything for it. You can quietly stay a Pythonista and use JavaScript at the same time, no conflict.

• Why I Left the .Net Framework: a developer named Jonathan Oliver also decided to lay out why he’s leaving his day-to-day technology, weighing the pros and cons of the Microsoft stack. No troll here; it’s actually a pretty interesting read.

• Java Again: anyone from the first generations of the Java community remembers James Duncan Davidson, creator of nothing less than the first Tomcat and Ant. He left Java, spent a while in the Ruby community, and threw himself into photography (go look for photos of the RubyConfs from eight years ago and you’ll see the official ones are all his). Now he’s announced he’s going back to Java.

• Why Go Is Not Good: as the title says, it’s a critique arguing that a freshly launched language should have been thought through better to cover cases other languages already handle.

• Rust vs Go: again with a whiff of sour grapes. Rust really does look like a technically superior language to Go in design and features, and the piece shows the frustration of watching Go stay more popular anyway.

• Why Perl Didn’t Win: mandatory reading on the fortunes of one of the most popular languages from the late 80s to the late 90s, which fell into obscurity and disuse. Even Swift, released by Apple weeks ago, already has more active users than Perl 6. One of the takeaways: anything new has to aim at the problems of the future, not the ones from the past.

Anyone from the first generations of the Ruby and Rails communities will remember the “traumas” we went through:

• Zed is Not Dead: from 2008, when one of our most prolific developers, Zed Shaw, creator of Mongrel and one of the first to take on the challenge of measuring and optimizing Ruby’s performance, announced he was leaving the community and moving to Python.

• Bomb: Merb and Rails Merge!: also from 2008, when the Merb team was on a collision course with Rails Core. The solution, happy for many and unhappy for a stubborn few, was to fold Merb into Rails 3, and it left dead and wounded behind. In retrospect, it’s worth reading “Learning from Rails’ failures” by Matt Aimonetti (who also moved to Go) and who counts among the wounded of that insurgency, and “The Rails/Merb Merge In Retrospect” by Giles Bowkett (still a Rubyist), who breaks down the results with a very critical eye.

• Twitter switches from Ruby to Java: from 2011, when Twitter announced it was replacing the messaging-infrastructure parts written in Ruby with a proprietary solution in Scala. What the original news said and what people chose to remember are two different things, but the fact is it turned into a good Public Relations headache for us. Thankfully that one’s behind us.

And these are just the links I’ve read and can recall off the top of my head. There are dozens more.

Anyone still young or inexperienced in software communities, especially newcomers to Node.js, must be asking themselves: “Now what? If someone important like TJ says he’s leaving, shouldn’t I leave too?” Do your homework and you’ll see this isn’t the first time. In 2012 the creator of Node.js, Ryan Dahl announced he’d keep an eye on his project but would step out of the day-to-day coding. “Man, the world is ending!”

This Isn’t Bad News. This Is an Excellent Opportunity! (Seriously!)

In 2006, right as I was starting my run as an activist in the Ruby and Rails world, I already knew what was coming. We were the newcomers, immature, with unfinished technology and a pile of expectations, so naturally the road would be as hard as it gets. That’s why I wrote the article Evolution through Competition.

A lot of people imagine the best of all worlds is the one where nobody questions what you’re doing, everyone leaves you alone, and they take your promises on faith, promises you fully intend to keep, someday. (yeah, right…)

I disagree. Any promise or expectation worth having has to be questioned, pushed, scrutinized. If it’s so fragile it can’t take criticism, direct and indirect attacks, and sabotage, then the promise was weak to begin with and didn’t deserve to move forward. The sooner it falls, the better, because that’s less time wasted.

That’s why I always welcome the attacks: I expect to be ready to hit back twice as hard or die trying. And I’d expect nothing less from the Rails community. Everyone still believes constraints are bad, but I’ve said before that constraints matter, because they’re the only place innovation comes from.

Anyone who has to reach for the old trick of trashing others, the classic “I don’t feel like getting better, so I’ll drag the other guy down to look bigger” (I wrote about this back in 2007 too, “For me to win, the other has to lose…”), is declaring himself weak all on his own. Stop and think back to articles, talks, and interviews where you heard someone you admire trashing another community. “Ah, Ruby, that girly thing. Because we men use JavaScript.” It makes me laugh and feel a little sorry, because to me it’s clear that person will always be weak.

All the statements above, and others like them (“I’m leaving Node”, “I’m leaving .NET”, “I’m leaving Ruby”, “I’m leaving X”), I honestly believe came with no bad intent or bad faith, at least not consciously. But I have a theory. Everyone who makes statements like that wants validation from their peers, or worse, wants their peers to follow them, which is also validation of their own position. “I don’t like my old toy anymore, but I don’t want anyone else playing with it either.” It’s a pretty childish stance.

Take the Ruby community as an example. Plenty of names sort of “left” their main activities without slamming the door or acting childish about it. Chad Fowler is in Germany running Wunderlist, focused on mobile and back-end development, and we don’t hear him talk Ruby anymore. Ilya Grigorik had his startup bought by Google and eventually dropped off too. Matt Aimonetti, after the Merb vs Rails episode, quietly stepped back and now works with Go.

Ryan Bates, one of the most beloved in the community for his tireless years of work on RailsCasts, stopped publishing months ago and said nothing about it. David Chelimsky, maintainer of RSpec, handed off the baton and stepped away without any fuss. José Valim, one of the key people behind Rails 3, is over in Elixir and Erlang land now and rarely says a word about Ruby.

“O.M.G! You mean it’s all over!? It went up in flames!?”

No. In the meantime, hundreds of new Rubyists showed up and carried the work forward. The most immediate example is Carlos Antonio and Rafael França, who sort of picked up José Valim’s mantle in Rails Core. Evan Phoenix picked up Chad Fowler’s mantle at Ruby Central. Avdi Grimm sort of picked up Ryan Bates’ mantle with his excellent RubyTapas, and on it goes.

A community is made of individuals, and each individual performs best when acting to maximize their own benefit. The side effect is that they end up naturally influencing and pulling others up alongside them. It’s always voluntary exchange for mutual benefit. Nobody acts with zero benefit to themselves; some believe they do, and those are exactly the ones who hit “burnout” fastest, because the question quickly becomes:

"Why do I wear myself out collaborating in this community, stress myself out, and even so not everyone appreciates what I do? I do it all for them!"

That’s the wrong question, and the wrong question leads to the wrong answer. Some start to believe others owe them something, since they poured so much of their free time (especially in the open source world) into “helping others”. And “the others” figure they owe nothing, since nobody asked for that effort in the first place. In practice, “the others” are right.

If you take part in a community, you do it for yourself. Maybe because you understand that helping others is part of your own reward. Maybe because it gives you peace of mind or a clear conscience. Or because you’re a good strategist and know certain contributions will open doors for you down the line. The reason doesn’t matter, as long as there’s a reward you don’t force others to hand over. Demanding respect, demanding manners, demanding compassion, none of it makes sense without a counterpart. Nobody asked you to do what you’re doing; if you are, understand it’s for yourself. That’s the definition of voluntary work.

And to be crystal clear: voluntary work means work without financial pay, and not work without benefit or purely altruistic. If your work is paid, that’s a different conversation, and the best advice there comes from Don Draper:

Back to the topic, I imagine the names I mentioned above, the ones who stepped back partially or quietly, get this. They went looking for personal satisfaction elsewhere. They owe nothing to anyone, and nobody owes anything to them.

The ones who leave with bombastic declarations are, consciously or not, throwing it in everyone’s face: “you didn’t value me, now you’ve lost your chance, and I know you’ll miss me!” It isn’t written that way, but that’s what it adds up to. Otherwise, why throw it into the fan and turn it into a public controversy? Any written argument is only part of the reason, never “the” reason.

You, the Individual

The flip side is whoever follows, admires, and idolizes one of these people who walked away from where you are. Depending on how deep the admiration runs, you feel the floor drop out, stunned, not knowing which way to run. One of two things happens: you either go hunting for another idol and start the classic “he wasn’t even that good”, or you sink into depression and the panic of “I don’t know what happens now”.

My advice: "don't have idols, have references."

Stop thinking you owe others something and, by extension, stop dumping on others the job of helping still more people. That’s what’s going on: you don’t understand your purpose and figure others should do what you yourself won’t. Worse, you let others decide which road you take. If you’re that insecure, stop for a second and think about what you “are” before anything else.

Your only purpose in life is to take care of yourself and produce, without getting in anyone else’s way. When you do that, the natural effect is that spontaneous collaborations spring up, communities evolve, and everyone comes out ahead. A community where everyone makes demands on everyone grows without any purpose.

On technology, opinions, proposals, and promises, remember this too: you want to be under constant “attack” and constraint. Nothing is worse than being ignored. I wrote another article, a translation from someone far wiser than me, Kathy Sierra, called Dilbert and the Zone of Mediocrity, where I quote:

How brave are you? How far will you (or your employer) go to avoid the Zone of Mediocrity? Until or unless you're willing to risk passionate hate, you may never feel the love. Scott Adams agrees. In a recent post on the Dilbert blog, he wrote: "If everyone exposed to a product likes it, the product will not succeed... The reason that a product 'everyone likes' will fail is because no one 'loves' it. The only thing that predicts success is passion, even if only 10% of the consumers have it."

So what if someone left your community? Is it so fragile that one blow, no matter the size of the impact, brings the whole thing down? If you believe your community is only resistant, you’re right: past a certain point, it collapses. But if it’s resilient, malleable and adaptive, it survives. That’s what guarantees the survival of species, the Law of the Most Adaptable (not the “strongest”! Keep the difference between resistant and resilient in mind, you want to be the second one).

Are you adaptable? Or are you just fishing for other people’s validation, letting them decide for you? One thing I’ll say for sure: if I ever give up what I do, nobody will find out from a written statement. I settled that the day I started.

He answered everything in colorful detail and we speak a lot about his open source projects, performance, scalability and, of course, lots of Git and Github stuff. Hopefully it will make people even more excited about how the Ruby/Rails community is moving things forward all the time.

aos leitores brasileiros: assim que tiver tempo irei traduzir esta entrevista.

AkitaOnRails: Ok, so, where are you from?

Chris Wanstrath: Right now I live in San Francisco but I grew up in Cincinnati, Ohio. I moved to San Francisco in 2005 to work for C|NET where I did PHP for a while on sites like gamespot.com, mp3.com, and tv.com

In 2006 I moved over to the chowhound.com site within C|NET to work on Rails, which is something I had been doing on the side for a while. While I was there P.J. Hyett and myself worked on chowhound.com then built chow.com, which we launched later that year. Then in April of 2007 we both left C|NET to form our consulting company, Err Free.

In December of 2007 we launched FamSpam, which is a site for keeping in touch with your family. It’s basically a simplified version of Google Groups with emphasis on participating in a thread at least once a week and easily finding photos or other file uploads.

While P.J. and I were working on FamSpam, Tom Preston-Werner and I were working on GitHub on the side. We started in October working nights and weekends on it. We basically wanted an easy, pretty, and feature-rich way to throw our Git repos up and share them with people. Then as we got more into it, we realized how things like the dashboard could change the way we deal with open source contributions. After that, all the social features began to fall into place. Github private beta launched in january, and in april we saw the public launch

AkitaOnRails: Wow, Cool, you are a very busy guy indeed, I want to go on in details within each topic you mentioned but first I knew you worked for C|Net because of your memcached keynotes. I have 2 questions: you were a PHP programmer, what made you switch to Ruby on Rails? And then, working for a high profile network like C|Net exposed you to very demanding public websites. How did you figured out about leveraging memcached with Rails and then your cache_fu plugin?

Chris Wanstrath: I started doing Rails at the start of 2005 and got my first PHP job in February of 2005. (before that I was doing asp and Perl, which I don’t like to talk about). So really, I never considered myself a “PHP programmer” over a Rails programmer. I really liked websites and I knew I could get paid doing PHP, so that’s what I did. In the meantime, I was constantly doing Ruby on the side.

When C|Net started doing Rails, I knew it would be a perfect fit for me. I really liked PHP and loved Gamespot, but it was just silly for me to spend all night playing with Ruby while doing PHP professionally.

In fact, one of the things that got me hired at Gamespot was my pure PHP yaml parser called SPYC (simple PHP yaml class). It was inspired (obviously) by _why’s syck yaml parser. I wanted an easy, extension-free way to deal with YAML in PHP because I was so spoiled by Ruby.

I think today the CakePHP and Symfony frameworks use it, and do their config stuff in yaml. But even when writing PHP I wanted to be writing Ruby. The main reason I picked up ruby in the first place is because I knew PHP, and I knew Perl, but I wanted something I could use to write both websites and command line scripts. Perl was great for scripts, and PHP was great for sites, but I was just tired of using them both

So while I was learning Python, Rails popped up.

As far as cache_fu goes, I was very interested in some of the “scaling” aspects of running a website while working at Gamespot.

While good OOP design and stuff like that can be learned by anyone writing enough code, you can’t really learn about scaling unless you’re working on a big website. There are just too many tricks and moving parts, and it’s too hard to simulate the load in a controlled environment.

So while at Gamespot, like I said, I tried to learn as much as possible about things like MySQL replication, clustering databases, sharding databases, and memcached based on how the smart guys at C|Net had set it all up over the years. They had a lot of machines serving a lot of traffic so it was perfect

At Chowhound, we were re-writing an old static html site in Rails and were worried about the transition from flat files to dynamic database calls and page generation. It had a fair amount of traffic from a group of rabid fans, and we knew the new “web 2.0” look of the site would not sit well with the old school users, so we at least wanted the site to be performant in order to give them one less thing to complain about. So we basically took a lot of what I had learned at Gamespot, and what information was freely available on the internet in mailing lists and discussions, and tried to do a more Rails friendly way of object caching with memcached.

Ruby is just so good at cleaning up repetition and creating friendly apis. So cache_fu does fragment caching and object caching, because in bigger sites you end up using both for different purposes which is how it was at Gamespot too, basically.

AkitaOnRails: Nice. And it is not very common for me to find people that have dealt with really big websites. Can you give us a glimpse of what kind of load your Rails apps did have to handle? Some pundits I know complain about the vanilla Rails distribution and recommend lots of tweaks like dumping ActiveRecord altogether and several other hacks. Do you have to hack Rails a lot in order to achieve the scalability you need or do you think most of it is good enough so you can avoid too much tweaking?

Chris Wanstrath: I wouldn’t really consider Chowhound to be a big Rails site anymore. Now that you’ve got scribd and twitter and friends for sale and Yellowpages, Chowhound doesn’t really make the list.

We ended up doing a lot of premature optimization on that site, and not enough real world optimization. I learned a lot of lessons there that I’ve applied to other sites along the way. However, I recently had the chance to work with the friends for sale guys on their Facebook app which gets millions of page views a day and handles an insane amount of db records.

To my knowledge, the only AR hack we did was apply Pratik Naik’s partial updates patch. This was because, with so many rows and such large indexes, you want to avoid modifying indexes when you don’t need to, so saving only the changed columns/attributes can have a real big performance gain. Luckily, partial updates are now in Rails Core.

In my experience, you spend a lot more time trying to scale SQL before you even need to address AR. And once you get to the AR part, it’s usually your application code. Fetching and saving too many records in before/after_save callbacks, full row writes like I was just describing, and generally not being a good SQL citizen. I would only ditch AR completely if I felt like I had no control over the SQL it generated. Which, as anyone knows, is not the case – you have a lot of control over it.

There are times, however, when AR is overkill and you really do need speed. On Github, we need to authenticate you every time you try and pull or push a repository over ssh. Loading an entire Rails environment, or even activerecord, was noticeably slow, so we switched to using sequel in a simple ruby script. Because we don’t need AR’s massive featureset and nice OOP capabilities for such a simple single row find, this made a lot of sense for us.

AkitaOnRails: I agree with that, that’s what I experienced too with regards to AR. So, and you’re also the author of several other famous Rails plugins like will_paginate, Ambition, the original Sexy Migrations. Can you comment briefly about each. Am I forgetting any other plugins? Some of what you did became the ‘de facto’ standards for Rails development, some people here use these plugins without really knowing you made them all.

P.J Hyett at SXSW'06

Chris Wanstrath: Err the blog is actually two people, P.J. Hyett and myself. I did not write will_paginate – P.J. wrote the original version then Mislav Marohnić re-wrote it. Mislav is now the maintainer. But I still get all the credit, which is fine by me.

As far as the other plugins go, there’s mofo, ambition, sexy migrations, cache_fu, acts_as_textiled, fixture_scenarios_builder, and gibberish.

Mofo is a microformat parser based on Hpricot. It’s up on Github and unfortunately doesn’t get enough love from me these days, but as far as I know it’s still the gold standard for microformat parsing in Ruby.

It was the first gem that I released which doubled as a Rails plugin, which is how I think most plugins should be distributed in the future. Gems already have a solid distribution system and versioning scheme, and if Github becomes a gem source then there’s almost no reason not to release plugins as gems

Sexy migrations were inspired by Hobo. Unfortunately their version was hobo-specific, so I wrote a plugin-friendly version. DHH later wrote his own version and rolled it into core, making a grand total of 3 distinct sexy migration implementations.

Gibberish is a pretty fun localization plugin I wrote pro bono for a client, just because I felt like the APIs of all the existing localization plugins were so difficult to work with. Hopefully, with the help of anyone interested, we can begin localizing Github in the near future.

Ambition was inspired by dabbling in Erlang. I read a blog post explaining that mnesia’s query syntax, which is all list comprehension (basically Ruby’s version of the Enumerable module), was made possible by the ability to walk the parse tree and build an mnesia query that way.

So I started playing with the parse_tree gem to see if I could do the same for Ruby. It’s now, of course, a full fledged framework for generating arbitrary queries for any RubyGem based on Enumerable. For simple queries, I really like treating tables as arrays, it feels very natural.

Acts_as_textiled was the first Rails plugin I released. It’s a testament to Rails that the plugin still works on edge today. The only other notable thing that Err started is the “vendor everything” term, which is now a part of Rails through config.gems.

That, and the Cheat gem (and site).

Tom Preston-Werner

AkitaOnRails: (Of course, pardon me P.J.!) And this raises another curiosity of mine: where did the name “Err” come from? It is both for Err the Blog and Err Free which is your company. And you mentioned P.J. and Tom. And you’re all full time Railers, right? How did you team up with them and decide to start your own company? Many times people ask me about entrepreneurship and you’re another good example.

Chris Wanstrath: “err” is kind of a play on “Typo,” which was the popular Rails blogging engine when we started our blog, so it may be kind of confusing, but I actually am cofounder of two distinct companies.

There is Err Free and Logical Awesome. Err Free is Ruby & Rails consulting and training. P.J. and I own the company, and we use it to do client work, speaking gigs, corporate training, that sort of thing. It also owns and operates FamSpam, which we use with our own families.

Logical Awesome, however, was founded by me and Tom. This is because I was developing FamSpam with P.J. and GitHub with Tom at the same time, separately. Today, however, P.J. is a part of Logical Awesome and is one of the GitHub developers.

Tom works at Powerset and doesn’t actually do much Rails for GitHub, he mainly does flash, haxe, C, css, design, and ruby. And because he’s the author of God, I make him write all the config files, too. As far as deciding to start a company, I am someone that needs to be involved in whatever I’m involved with on every level. At C|Net, there is only so much input you can have on a website that employs 30 people especially when there are dedicated product and “vision” people, whereas with Github, it’s just me Tom and P.J.

If the site is slow, confusing, sucks, or doesn’t improve your workflow, I can take responsibility for that. But if it’s fast, simple, awesome, and life changing, I get to take responsibility for that, too. Which is very rewarding.

It also means, when you’re cofounder of a mostly technical company, the discussions are a lot more logical. I saw decisions made at C|Net that directly contradicted a/b statistics we had gathered. At Logical Awesome, that would never happen. It is neither logical nor awesome. Basically: I wanted to find the ideal company so I found good people and started it.

AkitaOnRails: Ok, so we come to the main dish of the day: Github! I can’t think of a better example of an innovative product that leverages so well the power of Git. I am very curious to understand how did you come up with this idea? At the same time, lots of people still can’t understand why Railers as a whole started using Git so massively all of a sudden. Mercurial, Bazaar guys are very uncomfortable. What do you think Git has that attracted Railers in flocks like that? Or at least what do you think Git has that no other have? I started evangelizing Git here in Brazil last year after listening Randall Schwartz, and recently someone asked me what would be my pick for a Rails killer-app and Github popped out of my mind, right away. So you do have good mind share as well.

Chris Wanstrath: Github is super exciting to me because it’s really a website just for me. Tom and I are pretty similar in that we both have a fair amount of open source projects, all of which get used and patched by people we’ve never met.

Handling this the old fashion way was fine until me and P.J. started working on FamSpam… as my free time decreased, so did my ability to maintain my open source projects. And really, that’s a definite workflow problem. Sometimes when you can’t find enough time to do something, you just need to make the something take less time.

Github was literally written for chronic, god, ambition, will_paginate, and the rest of our projects. We wanted to make it dead simple for people to contribute, and really, it’s just not possible without Git.

I had started using Git right after viewing the Linus tech talk in May 2007, which is really good at explaining Git from a very high conceptual level. So when this time problem came up, I had already been using Git for a few months and Tom had serendipitously been trying to solve the same problem.

We talked after a local San Francisco Ruby meetup, at a bar of course (where all great ideas and partnerships begin), and decided to work on the problem together. I’d been playing with an err-specific Gitweb, but Github is obviously much more ambitious in its scope.

As far as the adoption of Git, I have no idea what single thing tipped it. When we began working on the app in October, we were worried about ./script/plugin and tarballs and windows and svn mirroring. we weren’t even sure we could build a business around Git, because subversion was still so utterly dominant.

As we all know, however, Git tipped at the start of 2008 and everyone somehow found the time to try it out. It maybe takes, like, two seconds to realize how much faster it is, and then a few more seconds after that to realize how much more awesome it is. So it’s not much of a surprise that it is grabbing converts.

As for the Rails community, it’s definitely because of the projects. When Merb, Rubinius, and Ruby on Rails all switch to Git, you have no choice. This is where the community is headed. As for other languages, we have a large number of non-ruby projects on Github. PHP, Java, Javascript, Lisp, Python — there are a handful of Django forks, for instance, the io and nu programming languages are also hosted on Github.

So really what it comes down to is early adopters, I think. Nu is a lisp written on Objective-C, very new and very cutting edge. The people using it right now are people who realize how powerful and awesome it is to run such a dynamic language on such a mature and stable platform. And naturally, the forward thinkers behind nu know that Git (and distributed source control) is an equally powerful, equally cutting edge concept.

With Prototype and Scripatculous moved over, and rumors of other Javascript frameworks switching, it’s only a matter of time before Git becomes even more widespread.

I think the Railers just like to blog a lot.

As far as other solutions go, it’s Rails vs Django all over again. If you use Mercurial, that’s fine. The two are so similar (yes, Git does work great on Windows) that as long as people move to distributed source control, it’s still a win.

Oh, but wait, Mercurial doesn’t have Github :-)

AkitaOnRails: There you go :-) And I wonder what were the challenges of putting something as Github together. It is not a simple Rails web app, with very fast, pure Ruby code. You’re probably dealing with thousands of system calls to Git command liners, several background jobs, maintenance, security. What do you think were the biggest challenges while assembling Github before recently releasing it to the public?

Chris Wanstrath: Well you pretty much nailed it right there… scaling Rails is the easy part. scaling sshd, Git, Git-daemon, and our background jobs is the hard part.

We call Git directly many times per page, we need to process jobs that get entered from many different places (create a repo on the website, push a repo through ssh), we need to be secure (ssl and ssh for all private repos at all times), we need to make sure it all runs fast (memcached for both Git calls and the db), we need to make sure you’re “in the loop” with a news feed aggregating information from all different sources within our system (almost 1m rows in the feed table when we launched).

So it definitely has not been easy. Not to mention that ssl is essentially the “slow flag” for http, so we need to make sure we’re going fast because things like your dashboard already have a speed handicap. As an example, sshd stores its keys in an authorized_keys file. Well, we weren’t even done with our beta yet and the keys file was over 4 megs of just plain text. So we had one of the C gurus at Engine Yard patch sshd for us to do mySQL based lookups, giving us faster searches and no pricey appending / writing of a massive file

Matthew Palmer is the said guru, and we plan to make that code open source in the near future.

We’ve also got post-receive (when you “Git push”) hooks running that we host and deliver – so if you push, we’ll POST to an arbitrary url for you with json of the commits. But you can also give us some info and we’ll post to campfire, irc, twitter, or lighthouse for you with custom payloads.

Since we have flash, flash with haxe, Python, c, ruby, bash scripts, lots of Javascript, and some forthcoming erlang under the hood, it’s definitely an interesting mix.

We are fortunate to be hosted on Engine Yard , though. If we didn’t have them we’d be screwed. Their awesome cluster setup with GFS means we can host our potentially 100s of gigs of repositories on a shared, raid’d drive with redundancy and backups. If we were running Github on a barebones VPS, I dont even know how we’d share access to those repos. It wouldn’t be fun.

They also have a lot of experts available 24/7, which is great because I have a tendency to forget to sleep and work until 7am. A lot of the pain of running a heavily unix-dependent site is taken away by those guys.

AkitaOnRails: Interesting, Erlang? I’d like to know what you are up to with it. Going back, I think I saw a Rails trunk Git clone at Github way before DHH announced it a few days ago. I think it was Michael Koziarski who first did it, without much fuzz. Were you planning this together with the 37signals guys, or the switch of the Rails Core to Github was something that happened naturally? And do you have any kind of partnership with the Lighthouse guys as well, because you already have some hooks to manage Lighthouse tickets through Github commit messages, right?

Chris Wanstrath: The Erlang stuff will be very cool, I promise. We’ll make a big fuss about it when it’s ready. As far as the Rails thing goes, koz did indeed have a mirror of his Git-svn repo at Github during the beta. It was unofficial. Then in february he wrote a post explaining that the core was thinking about moving to Git.

When I saw the post I emailed him and we talked a bit about what it would take to move Rails to Github, which was obviously something I love on a huge number of levels. He said he would get back to me, and then a few weeks later the Core team contacted us and wanted to discuss the move. The rest is history.

I really respect the work the Lighthouse team does. The bug tracker is great, and the new redesign is even better, but we don’t have any official partnership with them. We wrote the post-receive lighthouse hook because we wanted it, Rails wanted it, and a huge number of our users wanted it.

AkitaOnRails: Many others started moving to Github during the Beta. I think Merb was more obvious because of Ezra’s being involved in Engine Yard. Dr. Nic started using it for the Textmate bundles. Can you point to any other high profile Rails related projects hosted at Github right now?

Chris Wanstrath: Merb was actually the reason Github went into beta. We launched the beta so they could start using the site for their 0.9 rewrite of merb-core. As far as popular projects, the best thing to do is check http://Github.com/popular/watched and http://Github.com/popular/forked. Datamapper, Rspec, and Mephisto are some of the popular ones.

AkitaOnRails: Are you using vanilla Git code, or did you customize it in any way to better fit your environment? Have you ever talked to Junio Hamano or any other Git core maintainer? With Github probably eating up a lot of your time, how is Chow and FamSpam going right now? How are you managing all those products all at once?

Chris Wanstrath: We’ve patched Git-daemon to record statistics, which we’ll soon be surfacing on the website soon in the form of better, more granular activity. You’ll be able to see how many times your project was cloned, popular projects in the last 24 hours, all time most cloned projects, that sort of thing.

We’ve emailed the core Git guys about the site, just to say thanks for writing Git and to let them know about Github, but haven’t really had an occasion to chat with them about anything in particular. If I ever run into any of them, I’ll definitely be buying them a few drinks, though.

I don’t actually work at Chow anymore. My last day at C|NET was almost exactly one year ago, so my Ruby time is spent on FamSpam, Github, open source, and doing occasional client work.

FamSpam is going well. Now that Github is launched, there are a handful of features we want to get in and all. Luckily, however, the site is very polished and has been running smoothly without the need for much intervention. What we’d really love to do, because it’s really just a great Rails-based mailing list, is try out some different concepts.

Maybe one for open source, or a version for little league teams – anyone who needs to keep in touch and have their email workflow and document sharing streamlined. For right now, however, I try to spend as much time as possible on Github. There are so many places we want to take it.

AkitaOnRails: I probably more than exceeded my interview time (sorry about that), but this conversation is super-interesting. One project I just remembered is Sake. To me Sake is very neat because many people complain about “how difficult and complex” the Git command line is, and Sake-like solutions make the workflow a lot easier. For instance, my entire Git workflow for Rails projects is only 4 small sake tasks like Git:update and Git:push. If I am not mistaken someone at Err did Sake, right? Are you still evolving it?

Chris Wanstrath: Yeah, I wrote Sake. It’s not a Rails plugin but it was written to help in Rails development. The “Git tasks” for Sake are becoming quite popular, as Git really just facilitates a better workflow. If you want to implement it, or different branches of that workflow, you can pretty easily just wrap up a few commands into a rake task or bash script.

And while bash scripts are great, sake tasks are portable. A lot of sake was inspired, very loosely, on Git – you can pull in sake tasks from any text file, whether it’s on the web or local, and sake comes with its own daemon for serving your tasks.

So you could share tasks over wifi, or something, the same way you could share Git repositories over an adhoc network. Sake is up on Github, so feel free to add features you feel should exist.

AkitaOnRails: Another thing I would like to hear your opinion about. I recently made a presentation on Rails Deployment strategies for beginners. The most common simple architecture revolves around Apache/Nginx/Litespeed + Mongrel/Evented Mongrel/Thin/Ebb. It is usually a matter of load balancing between a Web server using some kind of IPC to distribute the load back to Ruby VMs running your Rails app.

Now we have mod_Rails. What’s your opinion on having all those choices, do you have any particular recipe you like or it depends on each application’s needs? Did you have time to test mod_Rails? I think Hongli Lai is doing great stuff in regards to things like mongrel_light_cluster and his efforts on making Ruby’s GC more copy-on-write friendly, did you take a look at that?

Chris Wanstrath: The nice thing about Engine Yard is they get to take care of all that stuff for me. So while I used to spend a lot of time benchmarking and playing with different solutions, like Mongrel vs Emongrel, I just let the experts take care of it so I can focus on Github..

So no, I haven’t played with mod_Rails yet because I’m not in the situation where I could deploy it even if I wanted to use it. Which is in my opinion the best situation to be in, and pretty much the reason mod_Rails was written.

AkitaOnRails: And by the way, are you going to make any presentation at RailsConf this year?

Chris Wanstrath: I am. I’ll be talking about “Beyond cap deploy”, which will pretty much be an in-depth look at the Github architecture, and then I’ll be on a panel with Ben Curtis, Geoff Grosenbach, P.J., and Tom about being a “profitable programmer” w/ side projects.

AkitaOnRails: I am very pleased to have the opportunity to talk to you.

Chris Wanstrath: Yes, you too. Thanks!

Last Tuesday (April, 24th) was a memorable day for me. I was able to have not only one, but two celebrities from the Ruby community. I interviewed Chad Fowler in the morning and then David Black in the evening. The original founders of the Ruby Central and two of the people most responsible for evangelizing Ruby back in 2001.

Both are veterans of our community and they were very kind. As you well know, I am a Brazilian Rails advocate and our local community is still small, but I believe the turn of the tide is not so far ahead.

My goal is to have known people speak to our local community so they can be inspired and motivated to not just jump into Ruby or Rails, but to aim for a higher level on their personal careers.

So, I will first present Chad Fowler’s interview, and next time I will publish David’s. Without further ado, here’s Chad:

AkitaOnRails : Well, not only software but I guess interviews have their own set of ‘Design Patterns’ as well. So, let me get rid of the ‘usual suspects’ before we get to the real juice. I personally like background history. How did you start in the computer world? I would guess you’re a self-learner programmer, one of the early hackers, is that right?

Chad : You are right. I went to college to get a degree in music. I was a jazz saxophonist and “classical” composer. I got interested in computer programming, because I have always loved computer games, and I wanted to write my own. Now, many years later, I still haven’t written a computer game.

AkitaOnRails : No kidding. Would you mind to tell us when was it? Your appearance may be deceiving. When I see a picture of you, it reminds me of Richard Stallman. I hope I am not aiming for a long shot. Was it in the era of the PDP-10 stuff or was it more recent?

Chad : haha. Very much more recent. I started programming in earnest only 11 years ago. I’ve always looked older than my age. Nobody ever said I looked like Richard Stallman before though. I actually don’t normally have long hair, but I’m growing it to donate to http://locksoflove.org.

AkitaOnRails : Haha, that’s nice. And going directly to the point: how did you find out about Ruby? What is Ruby to you? What makes you excited about it?

Chad : Having started as a musician and specifically a composer, I view computer programming as a creative endeavor. More of an art than an engineering discipline. I’m also a language geek, so I spend a lot of time exploring new (and unusual) programming languages. I discovered Ruby in 2000 during one of my Saturday language exploration sessions. I had actually planned to seriously focus on Smalltalk, but I spent that Saturday learning Ruby and it derailed me from my Smalltalk learning.

Ruby was a perfect blend of pragmatism and beauty/idealism for me. I haven’t found anything since which feels as good as Ruby. For me, the feeling I get when programming is at least as important as other factors when selecting a language.

AkitaOnRails : I see. Have you ever read Pete McBreen’s Software Craftsmanship?

Chad : Yes. I actually read that book on the plane to the first International Ruby Conference, which David Black, Dave Thomas, and I co-organized. Pete McBreen was at the conference and was one of the presenters. So I was able to get my book autographed. His thoughts on craftsmanship and apprenticeship are right in line with what I believe.

AkitaOnRails : Me too. I have a feeling that most of the ‘hackers’ consider themselves artists. Do you think that’s the case? I believe you met great hackers along the way.

Chad : I think he’s taken a somewhat extreme approach, and I’m afraid it’s a little more than what the industry can actually handle. It’s unfortunate that we can’t see more of this kind of thing in the industry. I would say that most of the great hackers do NOT consider themselves to be engineers. They might not all feel the extreme of being artists. Some think of software development as a craft, which I’d place somewhere in between art and engineering.

AkitaOnRails : Very well said. And speaking of the community, I hear that before Rails, the Ruby community was very small and all of a sudden it exploded. Do you think Rails is growing up too fast? Is the Ruby community comfortable with this fast pace? Or is it not so?

Chad : You’re right about the size (and pace) of the Ruby community before Rails. The first Ruby conference had 40 people at it. The 4th had 64 people. Not very fast growth. We sold out the 5th conference with 200 people and could have added more. There are certainly some growing pains with the explosion that happened with Rails, but I don’t think smart people in the Ruby community should complain. The explosion has brought us all into a situation in which we can work in our beloved language professionally. Until 2005, there were only a handful of Ruby programmers getting paid to work in Ruby full time outside of Japan.

AkitaOnRails : Right. RubyCentral is a very important institution in that matter. You’ve been responsible for many successful Conferences. How did you start it? And what are the values and ideas of RubyCentral?

Chad : We started Ruby Central primarily to handle RubyConf. In 2001, Guy Hurst was organizing the first Ruby conference and had some personal obligations come up that made it impossible for him to finish the organization of the conference. So, Dave Thomas (of the Pragmatic Programmers) stepped in to make sure the conference didn’t die when Guy stepped out.

He knew that a conference was an important milestone for the Ruby community. Dave enlisted David Black and myself to help lead the organization of the conference. After the first one, we realized it would make sense to establish a non-profit company to handle the conference in the future, which we did the following year.

As we’ve enjoyed more success in our events, we’ve started to branch out into other projects, including other conferences, sponsoring regional conference events, and funding “code fests”. As Ruby continues to grow, we hope to grow with it and to expand our role in the community.

AkitaOnRails : Yes, I heard about Guy, but very little. Where is he now? What is he doing? And were you all friends before Ruby? You, David Black, Dave Thomas, Guy?

Chad : I haven’t heard from Guy for several years. He was primarily a PHP developer, and I think that may still be the case. David, Dave, and I didn’t know each other before Ruby. We met on #ruby-lang on freenode back when there were only 12 people there on a regular basis. Since then, of course, we’ve all collaborated on many projects.

AkitaOnRails : You’ve been traveling a lot, you do many workshops, keynotes. I know that if people attend to your presentations is because they do have some interest in the subject. But did you find ‘skeptics’ along the way? Do you think people still think of Ruby as something over-hyped? Or are people getting used to it as a real-world solution?

Chad : I do still encounter skeptics. Most of the skeptics are Rails skeptics—-not Ruby skeptics. Rails is over-hyped. That’s a fact. It’s also a really powerful tool, so the hype is a good thing. Hype always turns some people off, but in this case it hasn’t turned enough people away that it is bad. I’m seeing more and more “uninteresting” uses of Rails and of just Ruby alone.

By “uninteresting", I mean that companies are using it for their intranet applications and other unsexy non-Web 2.0 applications. That’s a sign of maturity and that we’re moving past the early adopters on the curve and into mainstream territory. Ruby and Rails are being used for large and small applications. The cool thing, from my perspective, is that it’s no longer news when a company decides to use Ruby. Back in 2004, it was a big deal anytime a company made the choice to go with Ruby.

AkitaOnRails : I thought that the opposite was true: that Rails was used mainly as a startup resource to get to the market faster. Do you see traditional enterprises adopting Rails?

Chad : The opposite was and is still true. Startups are using Rails to great effect. But, now I’m seeing a lot more traditional enterprise adoption. The profile of the companies I’ve been working with has been changing and getting more diverse. Topics like system integration are getting a lot more interesting to the customers I’m talking to.

AkitaOnRails : At least here, I see that many IT managers and CIO’s still adopt the old IBM posture. If you asked a manager back in the 60’s: “Why do you buy from IBM?“, he would answer: “Because nobody gets fired buying from IBM”. Now, we have another scenario: “Why do you buy Java?“, “Well, because nobody gets fired buying Java stuff”. Do you think this scenario still holds true?

Chad : I think it will always hold true in big companies. Big companies make decisions based on fear. It’s not just true in IT. It’s true in HR, manufacturing, and other functions in big business. Fear-driven decision making comes from the way big companies are inherently organized and from the way promotion and success are measured.

I’m not sure there’s a way around it, other than perhaps treating big companies like a huge collection of small autonomous companies. I’ve heard of successful experiments resembling this idea, but I haven’t investigated in detail.

The funny thing about this kind of decision making is that it focuses on not failing as opposed to winning. You’ll very rarely see a huge success in an environment like this.

AkitaOnRails : Yes, indeed. I suffer this daily. I like this subject so I will return to it again. But changing subjects a little bit. I believe your most recent published book is Pragmatic Programmers’ Rails Recipes. I bought it as soon as it was released and I can tell that it’s an amazingly useful resource. I like the Recipes kind of book. Was there anything in the process of making it that you think was challenging or curious? Any tales about its making of?

Chad : Thanks for the kind words. The thing about the book that I always want to get across is that it’s truly a “recipe” book. Most recipe-style books are nothing but complete references, artificially divided into recipe format.

The equivalent in cooking would be to have recipes on topics like “How to throw a dash of salt into your food”. Nobody needs a recipe on a granular topic like that. Recipes should teach you to make something you didn’t already know how to do.

That was my focus. I tried to make recipes that were really compositions of many ingredients. The biggest challenge in writing the book was that Rails is a moving target. As you know, writing a book against something that’s constantly changing is not easy. I had to spend a lot of time in the source of edge rails.

AkitaOnRails : I know that, I also wrote a book that is already lagging behind (it was for 1.1). And you’re already preparing the Advanced Rails Recipes. As you evolved since the first book, what do you think of the current Rails evolution? Is it happening too fast? Are people having time to grasp all the new stuff?

Chad : I don’t think people have time to grasp the new stuff. Most people I talk to around the world still haven’t caught up with Rails 1.1. That’s an easy perspective to lose when, like you and me, you spend most of your time in the “alpha geek” Rails community.

Fortunately for us that are writing books, that means that out-of-date books are still valuable to “normal” Rails developers. I don’t think it’s bad that the masses can’t keep up with the evolution of Rails. It just means that the bleeding edge features are only being used by the bleeding edge developers. So far, Rails has stayed mostly backward compatible.

The interesting thing will be to see how the release of Rails 2.0 impacts the less-than-bleeding edge portion of the community. Rails 2.0 will introduce incompatibilities and will enforce new conventions/opinions on developers. I’m guessing it will be a messy and upsetting process, but we’ll get through it.

AkitaOnRails : I read a recent blog post about a keynote that I guess you did in March. I don’t know if it were your words, but the “Ruby is at a dangerous crossroads” statement caught my eyes. I think so as well. I would love to see you elaborate on that.

Chad : The primary reason I think we’re at a dangerous point in our path is this: Having been a niche player for so many years, we’ve had to kick and fight to defend our ground as a legitimate language choice. When you spend all of your time fighting, it burns its way into the community’s culture. Our default reaction to change is now defensive and argumentative. And, believing we’re on the cutting edge, we close our minds to suggestions from the outside world. This was OK when we were in defense mode, but now that we’re “winning” in terms of adoption, we have to actively change the culture of the community or else we run the risk of becoming closed-minded curmudgeons.

AkitaOnRails : That old rant from DHH: who wants to become mainstream? Do you think he still has this opinion? Many people follow that rant.

Chad : I think he still has that opinion, though he’s probably backing off to some extent, because we’re already becoming mainstream. I also happen to agree with him in some ways.

Matz gave a talk at OSCON 2005 called “It’s cool to be minor”, talking about the advantages of not being mainstream. Avi Bryant, of Seaside fame, also vocally enjoys the niche status of Squeak and Seaside.

Looking back at RubyConf 2001, we had 40 people in attendance, several of whom were authors of the Agile Manifesto. Still, others were authors whose books I had read and enjoyed over the months leading up to the conference. It was a small group of experts. Small communities are like that. Larger communities, like large companies, have priorities and focuses that are different. Both are good, but for alpha geeks like DHH, smaller is probably better for the creative process.

AkitaOnRails : Another phrase of the same blog post that caught my eyes was “Ruby 2.0 has been vaporware for longer than Perl 6.” It is very true. Ruby has been in 1.8 like forever. I believe that Rails was explosive in many ways. Over-exposure can be good or evil. You get famous, but you have to live up to it. Fortunately now I see lightning fast efforts as JRuby. What do you think of this situation? Can Ruby be doomed to be replaced by some alternative implementation, or Ruby 2.0 is real enough today?

Chad : I don’t think Ruby 2.0 is doomed. I was actually quoting Matz when I said that Ruby 2.0 was vaporware. Matz gave a talk on Ruby 2.0 at RubyConf 2001 (when we were still in Ruby 1.6.x). JRuby has also been in development since 2000.

I believe Matz has organized the team the right way now and is making real progress toward Ruby 2.0. I’m expecting to see a beta release by the end of this year as he has promised. Keep in mind that Ruby 2.0 is actually 2 different things:

1. a new VM (YARV)
2. a new language

The new language has been Matz’s interest and focus. Now that we have someone officially working on the new VM, Matz is freed to evolve the Ruby language.

AkitaOnRails : Sure, actually I feel that I saw both Ruby 2.0 and JRuby speeding up in the last year or so, more than in the previous years.

Chad : Very true. JRuby is speeding up due to the efforts of Charles Nutter and Thomas Enebo, who have recently been hired by Sun to work almost exclusively on JRuby. They’re putting in a lot of effort and it shows.

AkitaOnRails : Yes, I just saw 0.9.9 coming out yesterday. Amazing effort. I can picture them working overnight on this, it’s crazy. I am trying to have Charler Nutter interviewed as well. The local Java community will go nuts on this one.

Chad : Yea, definitely. The JRuby guys are definitely heroes in the Java world.

AkitaOnRails : Ruby is pretty much in childhood here in Brazil yet. It is taking a lot of effort trying to warm up the local community. At least from a distance I can see that the US and EU Ruby Community are growing very strongly and developing fast. You were there since the beginning. What do you think was the turning point for Ruby there? What did it take to make Ruby recognizable and respected?

Chad : Two things. The first was the fact that many of the industry’s thought leaders were long-time advocates of Ruby. Dave Thomas, Andy Hunt, Martin Fowler. All of them were using Ruby long before it took off. This set the stage for the Rails explosion.

When Rails came out, the hype was backed by some very well respected names in software development. Rails was, of course, the second (and largest) thing that pushed us over the hump. Most importantly, it was the marketing efforts of David Heinemeier Hansson.

Truthfully, Europe is lagging far behind the US in terms of Ruby adoption. India and other similar locations are far behind Europe. I think it’s a natural progression based largely on the economies of each region. I would guess that Brazil will come along in time. You just have to wait for the wave to hit you.

AkitaOnRails : Yes, the wait is really killing me :-) I see dozens of Rails and Ruby books at Amazon, and mine remains the sole Rails book here. It’s kind of sad. And it’s very hard to push the community forward because we have the very old chicken-and-egg situation: companies don’t want Rails because there’s no professionals available, and programmers don’t want to learn Ruby or Rails because companies are not demanding.

Chad : This is exactly the situation in India. I think that’s largely economics-driven. It will come to you, but if your primary market is serving others’ IT needs at lower costs, you’re going to necessarily play it conservatively and go for volume—-not margin.

AkitaOnRails : I spent a lot of time trying to understand that. Rails landed as a storm in the US. I can see the explosion. But it is very slow in other places of the world, like here. What is it so different in the US? I can’t believe it’s only coincidence.

Chad : Like I said, I think it’s largely economics. Living in India attuned me to the fact that in developing countries, the focus is on economic survival and financial success. In the US, most software developers just want to have fun. Given our financial success as a nation, we have developed a greater sense of entitlement. So we, more than other countries, view our work as something that has to be enjoyable, and we are therefore more likely to experiment and push the boundaries.

We don’t in general spend time worrying about keeping our jobs compared to people in other countries, because we feel we can get another job whenever we like. In other countries, there’s more of an emphasis on employment being a service to the employer as opposed to the other way around. I think in terms of ethics, the position of the average US software developer is inferior to that of developers in other countries, but it fosters innovation.

AkitaOnRails : You’re right on that. I’ll think more about it. And speaking of India. You wrote many things, but my favorite book is My Job Went to India. I can totally see the motivation to write such a piece with all that overseas outsourcing stuff going on. I read it and I found myself at home because I already live up to many of your 52 ways, although I never did any of it to “save my job”. I just do the things I do because I enjoy it. When did you have the idea to jot down those ideas? Any particular motivation?

Chad : Before I answer the question, I want to agree with you about “saving your job”. The title of the book was a mistake. My Job Went to India is really not about saving your job. It’s about creating a remarkable career for yourself.

I have spent a lot of time in India and elsewhere mentoring younger software developers on their careers. I’ve also done a lot of interviewing. Over time I’ve found myself explaining and motivating the same way over and over again. When I returned from India, I decided to leave my job at a big conservative company, which freed me to write without the constraints of intellectual property agreements weighting me down.

I talked to Dave Thomas about doing a book about how to do offshoring right, and it was Dave who actually turned the topic around and pointed out that I had a much larger audience which I could help by putting together thoughts on how to think about a career in this new global environment.

AkitaOnRails : Unfortunately I see many people here going the usual way: graduating college, maybe taking one Java certification or two and then simply stopping. From then on they just live in their routine. They’d rather have a routine than having to make decisions – and living up to them. I try my best to mentor as many people as I can. Any advice for this current generation? I know the question is too broad (the theme of an entire book), but you probably have something that you say to every youngster that you see with a question mark in their foreheads.

Chad : The only way to quickly sum it up is: have passion for what you do. Your work life is such a large portion of your total life, that you don’t want to spend it doing something you’re not passionate about. Don’t be afraid to take control of your career and to take chances. I would take that even as far as saying that you might have chosen the wrong field, and it’s never too late to realize that and make a change.

AkitaOnRails : Nice, that’s my motto as well. Many people simply refuse to think that way because their reasoning goes like this: “things that I enjoy don’t make me earn enough to bring food on the table, so I have to do what I don’t like so that I can survive”. It’s a sad reasoning. I know I am very fortunate being able to just go the way I enjoy the most, but many people find it too difficult to switch careers or learn something new. Education is expensive in Brazil, unemployment is a reality. Unfortunately there’s not too much that I can do but to mentor as many as I can.

Chad : Again, that’s an unfortunate reality outside the US, and probably another reason that the US is more innovative in the IT field. It is possible here to switch careers nearly whenever you like. And it’s much easier to get work based on merit and not credentials. So, I (for example) as a musician was able to build a career for myself in IT without having to go to university. I still have not taken a single computer programming course.

AkitaOnRails : You mentioned that you spent time at India. Do you see this kind of reality there too? People so focused on surviving and not on enjoying their work?

Chad : Yes, very much so. I would guess that the motivations behind professional life are very similar between India and Brazil.

AkitaOnRails : Have you ever been in Brazil our met Brazilians?

Chad : I have met Brazilians but not been in Brazil. I would love to visit, though!

AkitaOnRails : And about communities again. The Java community is very strong in Brazil. The sponsorship of Sun and the many years in the development raised a very strong foundation here. I still see a lot of animosity between Java guys and everybody else. They invested a lot of time in a single technology and it seems natural for them to bash everything else. Do you see it happening there as well?

Chad : I do. It’s a natural human tendency. And, if you think about it, Java, like Ruby , went through the same periods of having to sell itself early on as being a feasible technology. My fear is that the Ruby community now is like the early Java community, and that our fate is to become as closed and unaccepting of change and new ideas as many in the Java world have.

AkitaOnRails : Ok, I am very happy that we could have this conversation. Thanks a lot!

Chad : cool thanks!

The Dr Nic interview was a huge success and getting to know and exchange ideas with people as smart and intelligent is very addicting. So, I was again very fortunate to get in touch with Geoffrey Grosenbach , from Topfunky Corporation. He was very kind in accepting my invitation for this interview and sharing some of his experiences with us, Brazilians.

I am trying hard to get to know and interview more celebrities from our industry, so hang on there, because we may have more surprises.

It was a very long conversation, which I enjoyed a lot. We discussed a lot about him, his projects, the Ruby on Rails community and things to come. So, let’s get started.

Who’s Geoffrey?

AkitaOnRails : We know the name Geoffrey Grosenbach from the Rails Podcast and PeepCode. But again, who is Geoffrey Grosenbach? Where are you from? How did you get started at Rails?

Geoffrey : Who am I? That’s a big question, but I saw that you asked Dr. Nic, so I was expecting it. ;-) I got started in Rails about 2 years ago when I was living in Taiwan. I was a technology coordinator at an American school and wanted to keep up on what was happening in the web development community. I also had a few freelance gigs and thought, “I’ll try out Rails on one of them.” The client didn’t care what technology was used and it was a great opportunity to use Rails on a real project. That project was eventually abandoned, but I learned a lot. I started by reading through the entire online docs for Rails, which is probably something I should do again! At any rate, previously I worked for several startups, initially using Java and then Microsoft technologies (I live in Seattle), and also Perl, PHP, and the like. My college degree is actually in Philosophy , though, which I’ve never made a cent from (but it was a great topic to study).

AkitaOnRails : Nice. And what’s the deal about Taiwan? How long did you live there? It was just for some particular project?

Geoffrey : I lived there for a little less than 2 years. I wanted to live outside the USA for a while and a few friends had been encouraging me to come work at their school. There were some dry years in 2002-2003 where it was tough to get a good web development job here, so I took the opportunity. I taught a few computer-related classes to teenagers and also purchased equipment and kept the (Windows 98) network running.

AkitaOnRails : The post-Bubble era. You mentioned startups. Any known big names? And Jesus, Windows 98 in 2003? :-)

Geoffrey : Yeah, it was pretty sad. Fortunately it wasn’t Windows ME! I upgraded the whole network to XP while I was there. I also ran a few Linux servers for firewalls and such, and convinced the school to buy me a dual screen Mac. But as for startups….

I wrote data-mining type software for a company called Project Guides that was later bought by Onvia. Onvia was a pretty big company and sold computer equipment online before they went public. But now they have completely changed and are in the government contracting business.

It was a fun job because I basically created the position. I was hired to scan newspaper articles and run OCR software to pull out the text. (as a college internship). I thought, “Couldn’t this be done online?” So I researched the existing sources and wrote a proof-of-concept bot that would visit government project announcement sites and catalogue upcoming projects that companies could bid on. There was no RSS, so it was a lot of parsing of HTML to pull the data out.

AkitaOnRails : And all this in the Internet Bubble era? How bad did the burst of the bubble affected you, your life and your plans?

Geoffrey : Yeah. Well, with a degree in philosophy, I didn’t expect to be very wealthy. When I got that job doing programming it was a huge surprise. But I love to program (my first programming class was learning BASIC in 4th grade in the mid 80’s).

AkitaOnRails : And just out of curiosity, what led you to a Philosophy degree instead of, let’s say, Computer Science?

Geoffrey : I’m an avid self-learner and I felt that I would benefit more from learning many of the topics on my own instead of going through a program. After I graduated, many of my friends with CS degrees would come to me and ask how to do basic things like connect to a database or write a dynamic web page. I guess I just preferred to learn on my own, on the job, instead of in a class.

AkitaOnRails : Haha, I completely understand that. I have a similar situation. I’m a self-learner myself. But back to the first question. Isn’t it a little bit unusual to pick up Ruby as an option like 2 years ago? Or was it already famous there?

Geoffrey : I had heard about Ruby at about the time of the famous Dr Dobbs article in 2000 or 2001. I thought “That’s weird. Calling methods on a bare integer?” I wish I had tried it out more then, and I don’t know why I didn’t. I was trying other languages like REBOL and learning C and Java, of course. But why Ruby? I was doing some client work and stumbled upon Basecamp. From there I learned about Rails and decided to try it out. Also, I wasn’t working for a company that required a particular language. The school in Taiwan used Cold Fusion and I wrote some sysadmin scripts in Perl, but I could use whatever I wanted to.

AkitaOnRails : Do you work only on Rails nowadays? Maybe it’s time to ask about Topfunky. What can you tell us about it?

Geoffrey : Well, the job in Taiwan was on a 2-year contract. So I had to decide whether or not to sign on for another 2 years. I decided to come back to Seattle and that seemed like a good time to try to get freelancing gigs before applying to other jobs. Ironically, one of the jobs I did apply to would have sent me back to Onvia to write the next generation of bot software for them (as a subcontractor).

So I forget the exact series of events, but I started my blog and also got a small freelancing gig doing Rails. It’s been 100% Rails since then, mostly for PNN, a company near San Francisco. Actually, I’ve been working pretty consistently for PNN for about the last year and a half. But I’ll be going fulltime with PeepCode in the next month or two.

AkitaOnRails : I was gonna ask you that. Seems like PeepCode is very successful now.

Geoffrey : Oh, yeah, part of the deal was that I went to a Seattle Ruby Brigade meeting in the summer of 2005 that happened to be at Amazon.

The Rails Podcast

AkitaOnRails : You started it all together? The blog, the podcast, the screencasts?

Geoffrey : The blog first. I wrote the Sparklines library, inspired by a handout left on the table at Amazon. Then I did a few interviews for the podcast and eventually took that over. PeepCode is only about 6 months old, but has done much better than I ever expected it would.

AkitaOnRails : I haven’t listened to all of the Rails Podcast yet. Who was your first guest? Where did this interview idea come from?

Geoffrey : I didn’t start it, actually. Scott Barron, of the Rails core team did, based on a dare from Heinemeier Hansson. He interviewed DHH and then Dave Thomas, and then a month went by. I wrote to him and asked if he would publish an interview if I did one.

I’ve always been interested in recording and audio. Then I ended up doing 43 more and still going strong! My first guest was Thomas Fuchs, of Scriptaculous. Honestly, the sound quality was horrible initially. And I was a bit shaky on the interviews, but I’ve learned a lot in the process.

AkitaOnRails : Your last podcast episode was about Twitter, Alex Payne and the discussion around the scalability problem. I still didn’t have time to listen. How did it go? Is everything settled down already? They are not dumping Rails, are they? :-)

Geoffrey : I’m surprised that the Twitter issue has been such a big deal lately. There was that interview on a blog with Alex Payne and then the response from DHH, and it blew up from there. Hopefully this interview will command as much press as that one did. ;-) The podcast I did with Alex and Jack Dorsey, creator of Twitter, was pretty civil.

AkitaOnRails : Exactly, I’ve been following the flow of the events and it blew me away. But are the Twitter guys upset about all this fuss around them?

Geoffrey : They talked about the idea, how it took only 2 weeks to develop the first version. And briefly mentioned that they were having some scaling problems, which they were fixing. From comments by Blaine, their lead developer, they have been very open about it. They don’t seem to be too upset and have supported Rails throughout, while being honest about the issues they are tackling.

Rails Community

AkitaOnRails : And abruptly changing subjects, what about the conferences. RubyConf, RailsConf, US, EU, have you attended all of them?

Geoffrey : I’ve been fortunate to have attended many of them, yes. RubyConf 2005 and 6. RailsConf Chicago and London. I’ll be at Rails Conf Portland this year, and also Berlin. And I am going to GoRuCo in NYC tomorrow. I’ve missed some of the regional ones, such as the one in Salt Lake City and the SDForum.

AkitaOnRails : That’s the occasion where you do the podcasts? You hunt them all down and record them? Is that how it works? :-)

Geoffrey : I have always said that if I couldn’t afford the conference, I would just go for the afterparties! It’s great to meet people in person. I try to do as many as possible in person. Recording over Skype is a great option, but the sound quality is often poor. I like the on-the-spot, journalistic feel of doing it in person. And I just got a great little hand-held recorder that I take everywhere with me (the Zoom H4).

AkitaOnRails : Yes, that’s for sure, the afterparties! And I know the opinions will be biased in favor of Rails, but did you find any ‘skeptics’ between the audiences at the conferences? Do you feel they’re having a hard time learning or even using Rails at work? What’s the most usual good things or complaints you hear?

Geoffrey : Well, if someone is paying US$1000 or more to fly to a conference, buy admission, and hotel, they are probably not going to be a skeptic. But there is a great mix of people, some of whom are just learning about Rails. There are definitely some difficult parts of learning Rails, or at least parts that are unconventional. That’s what I try to cover on PeepCode.

AkitaOnRails : Are most of the programmers attending the conferences switchers, or do you see people starting their career going directly into Rails? Does Rails still hold the novelty status or is it well established already there in the US?

Geoffrey : Still novelty, I think. I’ve written to a local college and offered to give a presentation to their CS classes on Rails. They never wrote back. I think a lot of it is up to students to stay current and learn it on their own. Students write to me and say “Instead of going to a movie on Friday night, I bought a PeepCode and learned about Rails”. Which is kind of surprising! I also think that there are a lot of people who want to use it but are in a job where they can’t. But there is definitely more demand than there are programmers. So at least for now, people who know Rails can benefit from the novelty status.

AkitaOnRails : And are programmers getting used to concepts like “Convention over Configuration” or even the new RESTful approach of Rails 1.2? What do you think?

Geoffrey : Going into a bit of detail here, I think there’s a huge disconnect between people on the “front edge” of Rails who use trunk/edge Rails all the time, and those who are just learning and use the official releases. Even now, some people talk as if we’ve moved completely to the /articles/custom_action syntax instead of /articles;custom_action. So there are many people trying to learn Rails, or just get a product out the door that they have been working on for 6 or 9 months. For those people, there’s a lot of learning about the current styles that is difficult. Not everyone can rewrite their whole app every time the syntax changes. But the general ideas of Rails are leaking out into other frameworks, so I think people are becoming more familiar with the ideas, especially of REST. It depends on the person, of course.

Learning Rails

AkitaOnRails : Having made several podcasts, blogs and the teaching material of PeepCode. Where do you feel people are having the most difficult times about Rails? Where are they getting stuck at? Many people I know are a little bit afraid about the terseness of the syntax (mostly are Java programmers) and the lack of compilation (static typing).

Geoffrey : Two things,

1. The magic that goes on behind the scenes. In Django, for example, there’s a more explicit connection between the templates being rendered and the variables being passed. With Rails, there is a benefit of having things happen automatically, but it’s also confusing.
2. ActiveRecord. It’s still the biggest part of Rails and the thing that attracts people, even though there are other ORM’s out there. I think it’s all about the user interface and learning to take advantage of what’s there without getting frustrated by what’s going on under the covers. For example, I was debugging a weird issue with validates_uniqueness_of last night. I still don’t know what was going on, and it may have been a problem with how late it was, but the error was deep inside active record somewhere. If someone was just learning Rails and expecting things to work smoothly all the time, that would be really confusing.

AkitaOnRails : Were you using edge? or the stable release?

Geoffrey : Stable. But any programming project is going to encounter those kinds of issues. It’s just that people expect Rails to be 100% smooth sailing, sometimes (including me).

AkitaOnRails : Java was like that back in the mid 90’s. Now people are cleverer about it’s behavior. And speaking of Django, I remember that you interviewed Adrian Holovaty. He seems like a nice guy. How did you invite him? A Python guy talking in a Ruby show. And have you been using Django? I liked it a lot.

Geoffrey : Well, I’m interested in seeing other perspectives on languages and frameworks. I think that’s part of what attracted me to Ruby. Previously, one of the most popular interviews was with Avi Bryant, of Seaside and DabbleDB. So I think people like hearing from someone outside Rails every once in a while. I was in Chicago for RailsConf, and knew that Adrian lived there. So I met him at his office on Sunday morning. It was a great chat, although I understand Django a bit better now so I would ask different questions if I did it again. That’s still the most-downloaded interview, after the one with DHH.

AkitaOnRails : No kidding! I tell colleagues all the time: “don’t be limited to one thing only. Most of all, don’t be religious trolls!” I once made a joke: “you all sound like Sauron, one framework to rule them all, and in the darkness, bind them!” :-) Do you see people like that there as well? I hope they are diminishing in favor of a more open-minded generation.

Geoffrey : Strangely, many open source programmers approach software like a marketing department would. “We need market share!” Or religiously, thinking that you have to choose one and stick with it. But fortunately web services and remote API’s are changing that.

AkitaOnRails : Yes, it’s all about the APIs, “if it’s not an open API, I’m not using it”. Don’t remember where I heard that motto.

Geoffrey : Many people have a blog in Rails that imports delicious links from their servers running PHP, that tracks its stats from Google, running Python or whatever Google Analytics runs on. So there are many tools and they are good at different things. And by using others, you can loot their best ideas!

AkitaOnRails : I guess, it’s one of the most compelling things about all this “Web 2.0” talking. Not only the social networking aspect, but also the ease of interoperability.

Geoffrey : I’ve been using HAML for the last week, and I love the syntax, which is very YAML-like. Culturally, we do that, so it shouldn’t be a surprise that programming languages can do it, too.

Personal Projects and Discipline

AkitaOnRails : So, how’s your life with so many things to do, places to go and people to meet? Conferences, Topfunky, Peepcode, podcasts, interviews. How do you organize your many activities? Many people I know complain that they “don’t have enough time to learn new things”, as an excuse to not learn Rails or whatnot. Any tips for the audience?

Geoffrey : My model for personal organization and process refinement is Zed Shaw. I still need to interview him about it, but he keeps stats on how many bugs he writes, and then changes his workflow when it gets above a certain number. I’m not that smoothly engineered, but I do tweak my tools to get the most benefit. I use a few different to-do lists and project management systems (backpack, my own: The Online CEO). Mostly it’s trying to be aware of my own skills, needs, and mental stamina!

A problem I’m trying to figure out is how to maintain an open source project. I start a bunch of things and get patches from people, but don’t have time to actually apply and debug them, or rewrite them to work like I think they should. I’m thinking of running an open svn server where anyone can commit. Open source without the responsibility to keep a project going! ;-)

AkitaOnRails : You need to subcontract a maintainer :-) Nothing can be committed unless it goes through a peer review or a more serious test suite.

Geoffrey : Yeah, the problem is finding a maintainer who has free time. But it’s great to have a project that actually makes money, because it makes priorities clearer.

AkitaOnRails : By the way, what open source project?

Geoffrey : Well, I have a pile of 30 patches to Gruff that I haven’t had time to commit. And even some of my other Rails plugins and documentation, like the Capistrano recipes I posted for Dreamhost and TextDrive. I don’t even host Rails apps there anymore, so it’s hard to be motivated to maintain them. My wife loves to clean out the house and put a “Free” pile in front of the house. Usually, she can get rid of a pile of 20 or 30 objects in 24 hours that way. I need an open source version of that. ;-)

AkitaOnRails : Oh, that’s a nice subject I was almost forgetting: your open source projects. I understand you maintain some. Which is the one people like the most?

Geoffrey : Gruff is definitely the most popular. I enjoy writing graphical libraries, and use it in many of my own projects.

AkitaOnRails : Many people here probably are not familiar with Gruff. How would you present it?

Geoffrey : I started Gruff in the fall of 2005. Many people were on IRC or blogs saying “Where’s a good Ruby graphing library? I can’t find any.” So I was watching a movie one night and had my laptop. I started thinking about what kind of graphing library I would want to use, how the API would work, etc. By the end of the movie, I had a good start. So it does bar graphs, line graphs, pie, and a few others. It uses RMagick, which is the biggest problem. It’s hard to install all the dependencies. Ryan Davis, here in Seattle, wrote a pure Ruby PNG library. I’m hoping to use that to write a simple graphing library that’s all ruby.

AkitaOnRails : Yes, I heard about it. I hear that it’s more stable than ImageMagick (without the memory leaks)

Geoffrey : Actually, he has a few different ones in development. ImageScience does resizing. His separate png library can do drawing and render simple fonts.

Beyond Ruby

AkitaOnRails : So, have you ever been in contact with Charles Nutter, Ola Bini or anyone from the JRuby team? Are you following this subject? Do you have any opinion or heard any Java programmer talk about it?

Geoffrey : I interviewed Charles Nutter at RailsConf in London, a few days after they started working for Sun. I think it’s very exciting to see that project getting near to completion. The interoperability with Java will be a huge boost for existing Java projects. I’m also excited about the Rubinius project, by Evan Phoenix here in Seattle.

The early culture around Ruby in Japan involved a lot of experimentation and hacking on the Ruby interpreter itself. I’m hoping that Rubinius will make that possible for people who want to hack in Ruby itself. And will probably be faster and more maintainable, too. It also has some great features for introspection. Even methods themselves are objects in Rubinius, with some more features than Ruby has now.

AkitaOnRails : It’s one of the obstacles the JRuby guys are facing. Do you see a stronger exchange of assets between the projects? Together with XRuby, maybe?

Geoffrey : They are definitely working together. I know that all the alternate implementers met at RubyConf in Denver last fall. And I think they may even have a mailing list.

AkitaOnRails : And with all this turmoil around the community, what do you think are the most exciting developments going on?

Geoffrey : PeepCode, of course!

AkitaOnRails : hahaha, of course! :-)

Geoffrey : Seriously, I think there are so many great projects that it’s hard to keep track of them all.

AkitaOnRails : You’re right, it wouldn’t be even fair to pin point just one or two. I was going to ask who’s your all time favorite guest at the podcast, but it would not be fair as well. So, instead I’ll ask: have you ever come across some funny or curious situation during all those interviews? Something that stood out?

Geoffrey : I love being able to document Ruby history. It was great to interview Matz, and have him translated from Japanese. Jim Weirich is really insightful. Interviewing Marcel Molina and Sam Stephenson together was great. Marcel did most of the talking, but when Sam spoke it was just in these concentrated, concise insights. He would be a great speechwriter, and the speech would only have to be 2 minutes long to communicate everything effectively.

AkitaOnRails : The Core Team, yes. I remember that. He HAS to be concise: he writes a JavaScript library that has to load fast even in a narrow-band connection :-)

Geoffrey : Recording a ‘bootleg’ of the why the lucky stiff concert at SXSW 2005 was a lot of fun.

AkitaOnRails : SXSW, South by Southwest. Brazilians are not aware of this event. Can you quickly describe it? Who meets there, what’s it all about?

Geoffrey : Ah, it’s once a year in Texas. It’s part of a music and film festival, both of which are much bigger than the web development part. But almost every web developer who has written a book or has a popular blog is there (At least in English). It’s only about 3 days long, but it’s a fun time.

AkitaOnRails : I know many podcasters go there. Did you meet the guys from Revision3, TWiT, C|Net, Podshow and others? Don’t you have a Podcast conference in the US as well? Many Brazilians are only starting to grasp the beauty of podcasts.

Geoffrey : I haven’t been to any podcast conferences. I know a few other podcasters from Boagworld Podcast, Web 2.0 Show, but not many. I got an iPod video at Christmas and started subscribing to more since then, now that I have space to carry them all. I like Dan Benjamin’s Hivelogic Radio Show some video podcasts, like ZeFrank. I like more journalistic, in the streets podcasts rather than overly produced ones.

AkitaOnRails : Nice suggestions for our readers. Let’s jump to one last subject before I bury you with so many questions. What about the Mac? Why are Railers so into the Macs? :-) (I am a Mac user, by the way, but it’s always good to hear from others)

Geoffrey : I think Ruby has a great user interface for programmers, and people who like that sometimes like Macs, too. I think that as Ruby becomes more popular, there will be more content and help for people using it on Windows. My step dad was a teacher, so I’ve used Apple equipment since 1983. I feel that I live in a parallel universe to go to a Ruby conference and see so many Macs.

AkitaOnRails : I was surprised as well. And probably everyone that got there was caught off guard. Or weren’t they? Is this a Ruby thing, or it all started with Rails?

Geoffrey : I’m not sure. TextMate is definitely a factor, and the lightweight, don’t need an IDE philosophy of Rails. And now that people can make a good income writing Ruby code, it makes the price of Macs a non-issue.

AkitaOnRails : Jason Fried and DHH surely helped this matter. Looks like Apple will release Rails pre-configured in Leopard (when it’s finally released next October).

Geoffrey : I’m also interested in the Ruby integration with Cocoa for those writing Mac desktop apps. It’s crazy that Java is being abandoned for that on the Mac, but Ruby will have bindings that ship with Leopard (I think).

AkitaOnRails : Are you an Objective C programmer as well? I hear that the Ruby integration with Cocoa will be stronger in Leopard.

Geoffrey : I’ve done a little bit. I experimented with OpenGL quite a bit, a few years ago. So I wrote a simple 3D game in OpenGL and Objective-C.

AkitaOnRails : Java is being abandoned because Sun was never good to Apple. Linux, Solaris and Windows were all supported directly by Sun. I think I have recollections that Apple had to make their own JVM and support it all by themselves.

Geoffrey : Right, and it was always a bit slower than the other implementations. Objective-C is getting more automated memory management, if I remember correctly. So maybe Ruby integrating with Mac desktop apps will have a chance to do well.

AkitaOnRails : Precisely. Maybe Open Java will make things easier in a future Mac OS X iteration. Who knows. And speaking of the future, what are your plans for the future of your projects?

Geoffrey : I’m going to be working on PeepCode fulltime. I shouldn’t say “this summer” because I think you’re about to enter winter.

PeepCode

AkitaOnRails : Haha, yes, exactly. I personally like PeepCode, but I never heard of anyone else here buying it. Would you make translated versions?

Geoffrey : A few publishers approached me and wanted to distribute it, but I really want to stay independent for as long as possible, and I think I have some great ideas that they wouldn’t have supported as strongly. I started talking to someone about Japanese translations. I’ve gotten a few reviews in Portuguese, though maybe not from Brazil.

AkitaOnRails : Wow, count me on that if you ever plan on a Brazilian Portuguese translation ;-)

Geoffrey : Great! I’d seriously like to try that. I’m starting to branch out into topics that might have broader appeal. I’ll be releasing “JavaScript with Prototype” next week. I definitely want to release a Rails-specific episode every month, but I hope to add others on a variety of web development topics, too.

AkitaOnRails : Now, that is cool. Instead of focusing on Rails details, you will broaden the subjects. I bought only the first 3 screencasts yet. Have you ever done something on Mongrel or deployment and optimization procedures?

Geoffrey : I did one on Capistrano, and also one with Zed Shaw on benchmarking with httperf. There’s also one on Page, Action, and Fragment caching. I’m also hoping to cover other topics that are barely covered anywhere, like scaling with memcached and mogilefs.

AkitaOnRails : I HAVE to buy those. To let everybody here knows: how are the pricing models?

Geoffrey : It’s $9 for a single show (they last 45-90 minutes, depending on the topic). You can buy 5 or 10 for a discount (US$7/each if you buy 10). I’m also rolling out team pricing, so you can buy at a discount for a development team of 5 or 10 people. And I’ll be giving out free coupons on my blog and elsewhere.

AkitaOnRails : And what’s the size of each episode? How many episodes do you have so far? You mentioned Zed, so you’re not the loner host anymore?

Geoffrey : I have only 7 episodes so far. Most are over an hour, but all are at least 45 minutes. I was going to work with other authors who would do an entire screencast, but it ended up being too difficult for now. So I’m doing more of a collaboration where I do the screencast, but someone else is the technical editor and helps with the content. The good part of that is that I learn as much as the people who buy the screencasts! I’ve learned a ton about JavaScript in the last few weeks, and I’m working with Justin Palmer.

AkitaOnRails : Nice. PeepCode is only the name of the site? Is it a Topfunky related project? Or are both separated things?

Geoffrey : Topfunky is my company, PeepCode is one of my products. The business is just my wife and I right now. I hope to keep it that way for as long as possible, but I might hire someone short-term in the next year.

A Message to Brazil

AkitaOnRails : Ok, cool. Well, we could go on and on and on indefinitely (I’m loving this conversation). But I already have a lot of material here to work on. Anything else you want to talk about? Brazilian programmers, who are starting their careers, are very lost about what to do, what attitudes to have. What would be your words to them, as an experienced programmer and entrepreneur?

Geoffrey : My advice is to “stick it to the man.” There are so many opportunities for developers. With the internet, everyone has a distribution channel. Many people think that a business isn’t worth starting unless you can sell it to Google for 4 billion dollars, but there are so many ideas out there that would be perfect to support a small business or a solo developer. Then you can use the income to fund your next billion-dollar idea. ;-)

AkitaOnRails : yes, go on one step at a time. Kevin Rose is a bad influence to all those youngsters :-)

Geoffrey : Exactly. And you don’t even have to beat out the existing players in the market. There are many small niches that can support a person if the business idea is good.

AkitaOnRails : Jason Fried’s motto: underdoing instead of overdoing.

Geoffrey : Right. There are many businesspeople with great ideas, but they can’t implement them. As a developer, you have that skill, but you need the ideas. I’m not sure which one is more difficult!

AkitaOnRails : Ok, Geoffrey, so it was such a pleasure to have this chance talking to you. I do hope I didn’t bore you because we have to continue this conversation in another occasion.

Geoffrey : It was enjoyable, thanks! I’d love to come to Brazil sometime. I’ll be there if you host a Rails conference!

AkitaOnRails : Ha! You bet, I’ll invite ya! I just need to find a sponsor :-)

Geoffrey : Some of the best food I ever ate was at a Brazilian restaurant run by famous skateboarder Bob Burnquist.

AkitaOnRails : There in Seattle?

Geoffrey : No, in Los Angeles. The restaurant isn’t there anymore, unfortunately. Anyway, thanks for the interview! It was great to chat with you.

Today Carlos Eduardo, from e-Genial, proposed that I interview Dr. Nic Williams himself. The man of the hour. And I accepted right away and we started ‘skyping’ for a couple of hours. He is a nice guy and as educated and well informed as I expected. So, with no further ado, here it goes:

Who is Dr. Nic?

AkitaOnRails : So, let’s start by telling our readers, who is Dr. Nic – I know, too generic, but let’s start from here :-)

Dr Nic : I eat meat, am married, have a small boy, and I write software. In no specific order. I actually stopped writing software for a year or so – left my job and did other things. But everything I did had a software solution, so I found myself writing software for it. So, eventually, I learnt to love my inner nerd. Now I am happy :-)

AkitaOnRails : So, let’s do a combo set of questions. Where are you from? What’s your current day job, is it Rails related? And what’s your history with Rails?

Dr Nic : I am an Australian citizen, currently living in Sweden, working for a Swedish telephone company – Tele2 – for their billing project. It has nothing to do with Ruby. Two years ago I was in India, and was looking for a way to write code fast. I have a lot of ideas and it was taking a lot of effort to write them up in .NET. I saw this video on Ruby on Rails and my initial reaction was “I hate all the <% … %> syntax”. So I ignored it. I tried to make Ajax work with ASP.NET but it was so ugly and laborious at the time. I re-watched the Rails video and ignored the ugly brackets, and fell in love ever since. That’d be September 2005 I think

AkitaOnRails : So, I think you have some serious concern about the brackets. What’s your position about them today, did you get used to them or tried something else?

Dr Nic : No, I don’t mind them at all now. I don’t think I’ve ever tried an ERB replacement in Rails. I use Textile/Redcloth for the newgem website. It was just one of those initial reaction things. I saw the <% … %> and that was what might have stopped me learning Ruby. Oh, I also remember thinking “I don’t want to learn another language, how unnecessary”. I’m glad I was wrong. Learning Ruby was necessary.

Dr. Nic’s Magics

AkitaOnRails : I see that you like the ‘Magic’ side of the Ruby stuff. How did you come by with the Magic Model solution? I can guess that it felt quite natural, but what’s that story?

Dr Nic : At Railsconf 2006, Dave Thomas outlined a bunch of things he saw as “things we can work on” in Rails. One was lack of Composite Keys, another was the mysterious lack of DRYness in model files. I’d never released code to the Ruby community before (nor any community), but a few weeks later I just had these ideas for how to solve those two problems – both in the same week. I have no idea what possessed me to call the Magic Models that name. But I still like it. I just envisioned a magic show whereby you made the Model file disappear piece by piece yet it still worked. Thus the name. Ok, so I do know why I called it that. :-)

AkitaOnRails : From a marketing stand point, I find it fantastic. You could call it something fancy as ‘Houdini’ but Magic Models does the job. I have a feeling that this is your most famous open source Rails project. Am I right or is there any other plugin of yours that is more compelling to the community right now?

Dr Nic : I don’t think many people actually.. you know.. use the Magic Models. Deep down you need a model file as a placeholder for other functionality. So its more of a show-case of a concept. I have a 200 table schema that I use for a work. I use hooks to include additional stuff in the generated models. I hope that the New Gem Generator becomes popular. I’d like to see more people sharing code.

AkitaOnRails : So, what can you tell us about the Gem Generator. What does it do? What is it all about?

Dr Nic : Writing a gem from scratch isn’t simple/obvious. So ‘newgem’ creates a scaffolding for a gem, like the rails command creates a scaffolding for a rails app. It creates a folder containing a Rakefile, lib + test folders with some starter files, and a framework for managing a website on rubyforge.org. It uses the hoe + rubyforge libraries as they are awesome. If people knew how good these two tools were they’d write more gems and less rails plugins.

AkitaOnRails : Sounds pretty nice. It should make the deployment of new Gems a breeze. I am not very well aware of the RubyGems process and the RubyForge website. Have you tried to make some kind of partnership about the Gem Generator and the current Gem project? Maybe merging the two together to create a one-fits-all package?

Dr Nic : When I first created it there was a bit of chat about it with the RubyGems guys, but I don’t think its important. ‘newgem’ is one gem scaffolding app; the hoe gem comes with ‘sow’ which creates a similar structure. And I think someone else is creating a gem scaffolding app. So the more the merrier. You see the same for rails. You have the ‘rails’ scaffolding, but now there are “mega-rails” apps, like Hobo, that give you so much more of a headstart in creating an app. I start gems/projects because I need the solution and I think other people will want it too. If someone makes a better version, that’s great. I can stop supporting my version :-)

AkitaOnRails : Yes, and Streamlined and AjaxScaffold. I was hoping to see both of them releasing new versions sooner. They announced a merging collaboration but I never heard from them again. Have you?

Dr Nic : AjaxScaffold became a plugin and has now been rebranded as ActiveScaffold. Its still under active development by Richard White + others. Actually, AjaxScaffold was the first project I ever helped with, before I wrote CPK + Magic Models. So I learnt a lot about gems and rails generators from its code. I’ve never used Streamlined but its still under active development as far as I know. I’m not a fan of open source projects merging. Often they are built around the inspiration of an individual. Those individuals mightn’t share nicely together :-) Plus, its a whole bunch of work to merge two blocks of code.

Open Sourcing

AkitaOnRails : Going back to your previous statement: don’t abandon your project. Fight for it! :-) But talking seriously, development and support require a lot of effort. Mainly with support, bug fixes and all. Do you get a lot of help from the community, maybe patches?

Dr Nic : Help + patches – that has turned out to be the best thing about open source (OSS) – people fix your code, or at the very least ask “why didn’t you do it [an alternate] way?”

AkitaOnRails : Hm, let me digress a little bit. I have mixed feelings about merging and forking. I usually don’t like forking unless the original team have gone numb like what happened to the XFree86 project. Alternatives should really be very different like KDE and Gnome, and they are fine. But components that do most of the same things or complement each other like the current beryl and compiz discussion, maybe it’s ok for them to merge and focus effort on a single direction. What do you think? For instance, I think that a multi connection support like yours or Rev.Health’s one should be in the main Rails tree. It’s as important as the database adapters. Or maybe not?

Dr Nic : There is a project DRYSql that is for all intents and purposes similar to the Magic Models. It’s not a fork, but the code would be similar. But I’m glad he did it. I think OSS is driven by inspiration – and people like to have their name attached to code. If he writes more code because it has his name on it, then that’s great. Regarding more vs. less in Rails – I think more code should be extracted from Rails, rather than more code added to Rails. Unfortunately if you take things out, then the anti-rails movement say stupid things like “Oh rails can’t do XXX” even if there is a plugin/gem that can do it, or even if you could do it in 5-100 lines of purpose built code. But we’re not here to make the anti-railers happy, just ourselves. So, extract code out of rails-core and set it free.

AkitaOnRails : Yes, like the current desire to cut out the Active Web Services support as it seems like fewer people are using it, and make it into a plugin. That’s right, the more it is in the core, the heavier it gets to load the process.

Dr Nic : Let people choose prototype/scriptaculous vs. jquery for example. But, no one will do that – not worth the effort. And right – no need for AWS anymore – its already packaged as a separate gem. You just stop making it a dependency in the rails gem. So that’s an easy one. But my attitude is that Rails is perfect given that it’s only a few years old, completely Open Source, and has a wonderful community of intelligent, caring developers who can “scratch their own itches” and then share the results via blogs + forums.

AkitaOnRails : I am personally a little bit worried about this because Rails is becoming something as the Linux kernel. Linux doesn’t have a specific set of stable APIs, so each new version has to tweak some of its drivers. It works because all of the drivers’ source code are in the main tree. Rails is like the same: I asked DHH (refer to my book’s interview) about stable APIs and he is not very fond of limiting what he wants by providing stable APIs through out newer versions. So plugins are destined to fail someday unless they are delivered along side the main distribution. Maybe we’re going to see ‘Rails Distros’ in long run?

Dr Nic : Fragmented rails – yep that’s a valid concern. I think you will see “rails distros”. I think they already exist. But they aren’t called that. Hobo for example could be a rails distro. So one day we could have a HoboConf.

AkitaOnRails : Actually I just got into this Distros conclusion. Maybe I should start assembling my own :-) The Akita Rails Distro.

Dr Nic : Just make sure you do screencasts. They sell software. Having given that pearl of wisdom, I’m not sure why I don’t do them. Writing blog articles is fun and time consuming, that’s probably why. But videos work. Rails success will be noted in the history books, in part, to that 15 min video.

Twitter vs. DHH – Round 2

AkitaOnRails : Speaking of which, support, plugins, I have to ask you something delicate (I don’t want it to become an excuse for another flame-war): what do you think about the current Twitter vs DHH discussion? Twitter says: Rails should have given us the solution. DHH says: Twitter could have contributed back with a solution. I think this kind of argument doesn’t do any good for the community, as I posted at my blog yesterday. What are your insights about it?

Dr Nic : The guys at Twitter have already contributed code to Ruby community (Jabber API), and when they settle on a solution for their situation, I think they will be very happy to share it with us. That will be great. Remember: Rails is 2 years old. .NET + ISS is 7+ years old. Java is 10 years old. LAMP is very old. So, its all in front of us. Exciting times.

AkitaOnRails : And you didn’t get your t-shirt, or did you? :-)

Dr Nic : No one has asked my address – a query that preludes the sending of t-shirts.

AkitaOnRails : hahaha, and did you get feedback from the community about the magic multi connection (MMC) and the Twitter discussion? By the way, how did you come by the global array of connection modules solution?

Dr Nic : I think the most important aspect of the MMC is that it answers the doubts of whether Rails CAN connect to multiple databases. It is a silly thing to say “Rails cannot connect to multiple databases” but the anti-railers like the way it sounds, I think. Even without the MMC, you can create your own connection pool, and manually assign the connections before each request. The MMC hides this via modules. Revolution Health’s solution moves the allocation of connections into the CRUD methods. All the same solution. Just different levels of control and different syntax.

AkitaOnRails : But did you think about that before, or was the heat of the discussion what motivated you to hack together a solution?

Dr Nic : I’d written the gem a week earlier to scratch an itch. The idea of using modules to control ActiveRecord model behaviour appeals to me from a “magic” sense. Its cute. For example, the latest Magic Models allows you to use Modules to specify table name prefixes. So, I had the gem, and Twitters issue turned up. So I wrote the blog article and the tutorial as a result. I was going to release the gem in a few days but not aimed at the master-slave issue. It was built with the aim of using it for admin websites that need to connect to 2+ different databases. I’ll blog about that later.

AkitaOnRails : Really excellent timing. Did you hear something from the Twitter guys? Now someone has to build a screencast explaining Railers how to set up a master-slave replication between MySQL databases first :-)

Dr Nic : I think more Railers are interested in how they get their Rails app into production in the first place :-) They dream of having scaling issues. “Oh, my Google Ad-sense account is full. What should I do with all that money.”

Community and Macs!

AkitaOnRails : Speaking of the community, do you attend to a lot of conferences, events? Have you been in the latest RailsConf EU? What are your opinion about what’s going on around the community?

Dr Nic : I met only a handful of people at the Railsconf 2006. I sat in the audience watching all the famous Rails bloggers speak, like everyone else in the audience. I felt very happy to be there. I was one of 50 people with a PC laptop. I did a lightning presentation on RadRails vs TextMate for a few laughs. Travelling from Europe to Chicago cost a bit of money, so even though RailsConf EU was across the channel in London it was vetoed by the Williams financial panel. But I’m off to RailsConf again in May, should be wonderful. The community of Rubists is awesome.

AkitaOnRails : (I wish I could be there as well – sigh) well, so it means your primary machine is Windows based. Are you still using RadRals or have you tried the newest contenders like “E” or even the NetBeans and IntelliJ’s Ruby integration?

Dr Nic : Ahh, it was a PC. I bought a unix laptop, with an Apple logo :-) The PC was old and making a lot of whirring noises. I just couldn’t find a reason to stay with the PC vs. the possibilities with OSX. I’m not an Apple Fanboy, but I love my Mac.

AkitaOnRails : Let me guess: Macbook Pro 15" Core 2 Duo 2.33?

Dr Nic : Macbook 13" – I use it on the bus and train.

AkitaOnRails : Haha, I also say that: “I’m not an Apple Fanboy”. Maybe someone should create the category of “the Deniers” :-)

Dr Nic : I love my wife, my son and my mac, officially, in that order.

AkitaOnRails : I wish I could use mine at the train, but I would be robbed in less than 10 seconds. No doubt about that.

Dr Nic : Ha. Its a big planet. You could move.

Dr. Nic’s Career Advice

AkitaOnRails : Nice proposition. I am thinking about it. By the way. At the beginning of this conversation you told us that you’ve been working in India? How come? Any kind of consultancy work for any of the major companies like Tata, Wipro, Satyam? What are your opinions about the recent discussions and worries, like the Chad Fowler’s book My Job web to India?

Dr Nic : I went to India for the same project I’m on now with the Swedish company. Back then it was for Accenture, who were doing the work at the time out of India. I have a copy of Chad’s e-book… damn, haven’t read it yet. But thanks for the reminder. I have lots of thoughts about “outsourcing to India”. But they aren’t positive, so I’ll take a pass. They are more the topic of conversation when alcohol is involved. :-)

AkitaOnRails : haha, if you ever think about doing outsourcing services, consider Brazil. Did you hear anything about us in outsourcing conversations?

Dr Nic : Never. People who I hear talking about outsourcing mention “India”, several asian countries, and eastern european countries. Never Brazil.

AkitaOnRails : Damn, I knew it :-)

Dr Nic : So, just pretend you are American and ask for American rates.

AkitaOnRails : Good advice. I just wrote an article about the importance of being fluent in english at my blog. That’s one compelling reason.

Dr Nic : Absolutely. Clients don’t pay per line of code. They kind of pay for results, and kind of pay for working with people they like and trust. I think.

AkitaOnRails : And I agree with that statement: people hire competency, in general. And have you ever considered flying down on vacation to Brazil?

Dr Nic : Absolutely, its on our list of places to visit.

AkitaOnRails : And what do you know or hear about our humble home country? (default question to a foreigner, I had to ask.)

Dr Nic : Football, poverty, women, the big statue on the hill, and the Amazon.

AkitaOnRails : I bet it’s better than New Delhi or Bangalore.

Dr Nic : They have poverty, but no statue on a hill :-)

AkitaOnRails : Well, I guess I already took a lot of your time. What about calling it a day? Do you have anything you want to say to the brazilian audience? Career Recommendations? :-)

Dr Nic : Career advice… Learn English, be proud of being Brazillian, and enjoy writing code.

AkitaOnRails : ow, last question! Is Nic short for Nicholas? Dr. Nicholas Williams?

Dr Nic : Correct. PhD in Computer Science. I just use the Dr Nic name ‘cause it’s a bit different. I don’t mean to show off the “Dr” part.

AkitaOnRails : Very nice! Dr. Nic, then :-) Very glad for this opportunity. I look forward to more conversations like this. Too bad we can’t do it in a bar with beers.

One such data point is this survey: Survey says 75% of IT professionals want to change jobs. It’s old, from the middle of last year, but I see it in practice. A few days ago some friends came to me with exactly this: “I’m unhappy with what I’m doing.”

These articles need to be taken with a grain of salt, since most of them report on the American market. This other one, for instance, says programmers are the highest paid in tech. In Brazil that’s not necessarily true. Here the programmer earns “enough,” and the bigger paychecks go to analysts (people with degrees in all sorts of fields who use technology as a work tool). And it’s precisely those analysts and consultants, some making up to R$100,000 a year, who complain the most about their own salaries.

Another complaint I hear all the time: “I’m not enjoying where I work anymore because it doesn’t ‘add’ anything to me. I want to move to other projects to learn more.” Wanting to change is admirable, but I believe most people are aiming at the wrong target. A colleague of ours put it well: “the vast majority of projects are all the same: data entry screens and more data entry screens.” That’s exactly it. It’s the descendant of the old field called Data Processing, which people now call Information Systems.

There should be more than that. Outside of programming you have Business Intelligence, Customer Relationship Management, Supply Chain, and several other cutting-edge areas, the ones that set apart the companies that already control the basics: accounting, sales, purchasing, manufacturing, maintenance, quality control.

In Brazil, the vast majority of “programmers” customize processes that already exist. One department wants to automate employee records: it buys or builds its own forms. Another wants a sales form that feeds the sales system and notifies an external partner to update inventory. Another needs screens to control a customer service workflow. Forms and more forms, always some variation of a form.

No wonder so many programmers are dissatisfied. Usually they can’t say why, but they feel something is wrong. And please, don’t take anything here literally. There are dozens of fascinating projects out there, with complex algorithms for medical technology, aerospace, engineering. I’m talking about the majority, not everyone.

This cycle of data entry is old. Since COBOL, since the 70s, data processing brought dynamism to the modern world, eliminating tons of paper and legions of bureaucrats whose only job was to fill out and control that paper. And it will never end, unless computers get smart enough to stop needing “mere” programmers. You never know.

Meanwhile, the market will keep needing “data entry programmers.” It doesn’t matter whether you use Struts, Spring, Rails, or Symfony: you’ll be building user records, client records, material records, content records, complaint records, contract records, address records, vendor records. The list is enormous. Especially where “modernization” hasn’t arrived yet, where bureaucrats abound and processes haven’t even been stabilized, let alone automated.

I started out building data entry screens in the late 80s, with dBase and Clipper. Most of the client-server era (2-tier) was exactly that: a database on the server and entry screens on the client. When the Web arrived, seductive applications showed up, search engines and webmail, and suddenly everyone wanted to build a website. Whoever invented TCP/IP, HTTP, HTML, SMTP, POP3 must have had a blast. For the rest of us, what was left was more data entry. An email screen is a form. An e-commerce screen is a form. Companies swapped their Visual Basic screens for browsers: data entry dressed up as web pages.

It’s no coincidence that so many frameworks keep popping up: Struts, Velocity, Lucene, Jackrabbit, Spring, Guice. A real programmer loves the plumbing. We like understanding how this mesh of code works, how to optimize it, how to make it stable, how to wire things together. Plenty of people in Brazil think this way, but far fewer than in the United States. We have nothing even close to a repository like Apache Jakarta. Brazilians contribute to various open source projects, but it’s a small fraction.

I can see it in the Rails case. Rails appeared recently, and it didn’t come out of the US. Even so, it spread fast over there. Here, aside from small communities like the competent RubyOnbr, we have nothing: nothing interesting in the media, nothing interesting at conferences (which are few to begin with). Nothing, zip, nada.

My book, “Repensando a Web com Rails,” barely sold its first print run of 1,000 copies. The excellent “Agile Web Development with Rails” sold tens of thousands abroad. Setting aside which book is “better” or “worse,” the meteoric sales, the dozens of other titles launched there, and the fact that mine is still the only one here are a thermometer of the cultural difference, in the market and among programmers alike.

Fair enough: we went through a dark period of closed markets and years of lag. But today I see no reason for programmers, especially the younger ones, to be so apathetic about technology.

At times like this I miss the late 80s (that’s the era I lived; older folks will feel the same about the late 70s). We were very few, and running into a programmer or even an enthusiast was rare. But we thought differently.

Even in the mid-90s, just before the internet boom, my friends and colleagues were all in love with technology. We talked about what was new, what each of us had learned, what we were testing. We traded ideas, argued techniques, and the goal was always to learn more. I knew people whose hobby was writing little animations in Assembly. Others bought electronic components to build their own MP3 player (iPods didn’t exist yet). Some spent hours building tools for this thing called the “internet” that was still new to us. Those were good times.

Then the Brazilian IT market exploded, for all sorts of reasons. Suddenly a lot of people saw the field as a quick way to make money. Suddenly universities were packed with kids learning tools instead of technology, graduating as information systems technicians where computer science graduates used to come out. Suddenly everyone “knew” Java. And finally the market was saturated with “programmers.”

Now all I hear from today’s “programmers” is “which language do you think I should learn that will make the most money?” You can imagine how frustrating that is for someone who already feels like part of the old guard. I never thought about the cost-benefit of learning time. I always took learning as a constant; if I made money along the way, great, but that was never the point.

Because of the current state of absurdity in the market, I witness things that scare me. At one client, they “integrated” the sales system with the activation system for a piece of equipment. The logic is simple: once the sale goes through, the customer’s equipment should be activated. Even without a two-phase commit solution (everyone knows what atomic transactions are, right?), the requirement called for safeguards to guarantee that.

Obviously there were no safeguards at all, and nobody ever asked: not the programmers, not the analysts, and certainly not the managers. The result: today several people are employed whose only job is formatting spreadsheets full of errors and fixing them by hand. More data entry screens were built to handle those errors. Did the project deliver automation gains? Sure, but far less than it should have. And nobody cares. I’ve seen worse.

It saddens me to see how little knowledge the bulk of programmers and the whole chain above them (programmers turned analysts, programmers turned managers) actually have, and how poor the architectures and solutions they produce are as a consequence.

Back to the questions people asked me: the unhappiness with what they do, the feeling of not living up to their “potential,” the urge to learn something new to earn more money. I have no answers for that because I can’t think that way. More than that: I believe those questions are fundamentally wrong. And a wrong question has no right answer.

I try to spread the culture I knew as a young programmer: learning. The excuses I hear are always the same: “I don’t have time to learn when I have to work to support myself”, “I can’t read English, so I need courses and can only learn one thing at a time”, “no point learning this ‘X’ thing because I don’t know if I’ll use it at work”, “I’m stressed enough at work; in my free time I just want to rest.” And so on. A long list of excuses.

It’s human nature to resist leaving your comfort zone and, worse, to complain when you become obsolete. “It’s the government’s fault”, “it’s capitalism’s fault”, “it’s my boss’s fault.” More excuses.

When I wrote my book, I did it for two reasons: to learn something new and to help others learn along. Learning and Teaching are the two fundamental motivators of every good programmer. I understand that in Brazilian reality, ignoring money is not an option. I found a balance between the two, and I don’t see why nobody else could. Standing still, sitting on the little you learned years ago, complaining nonstop, never got anyone anywhere.

If it’s worth anything, here are some personal suggestions:

• The more you learn, the better your solutions. Clients recognize a professional who knows what they’re talking about, and everyone can tell when someone is just bluffing.

• The demands that will grow the most are systems integration and analyzing large amounts of data. The only way to deal with that is knowing dozens of concepts and technologies. Learning one tool in a course won’t help.

• The technology cycle keeps getting shorter. A new version used to take years; now it takes months. By the time you finish the course, what you learned is already obsolete. Deal with it. Get ahead. Learn as much as you can before the technology is even available.

• Jumping from job to job doesn’t solve it. A new project won’t necessarily bring anything new (the odds of it being just another data entry screen are high). And leaving it to learn only when you already need to, inside the project, is too late: you’ll be overtaken by people who know what you should already know. A good programmer learns ahead of need. Once a poor-quality product hits production, the result is bad for the client and for your reputation.

• Try to innovate inside your own project. I’m not telling anyone to risk a project by bringing in things so new they could blow up the next day. There’s always a better way to do what you’re doing without touching the schedule or the cost. Learning to be efficient with quality is part of a programmer’s job, and it takes a lot of practice.

• Think you’re a good programmer but underused? Then put yourself to better use: create or join open source projects. That’s one of the qualities of open code: you get to use for free what others built, learn from a solid base, and still have the chance to give back.

• Stop complaining. Complaining builds a negative mindset, annoys everyone around you, and leads to no solution at all. A complaint is one more excuse, noise that hides the real problem. And the real problem is this: you complain about the job, the project, the boss, but the person you really want to complain about is yourself. Complaining is the externalization of the frustration of being who you are and failing to become more. And that is not a physical incapacity: it’s mental laziness.

• Forget courses and translated books: they’re always outdated. In the 80s we had no certifications or games of that sort. We slept with an algorithms book on the nightstand and woke up to a new language spec over breakfast.

Good cooks appreciate good food on vacation. Good engineers analyze their own car on a road trip. Good artists sketch new ideas on a restaurant napkin. Good professionals LOVE what they do, and not only at work. Loving it here means appreciating, respecting, and wanting to learn more about the profession, which is very different from taking work home. Da Vinci didn’t need courses. Mozart didn’t need courses. A course only helps someone who is already on track and knows exactly what they want out of it.

When I buy my iPod I want to know how it’s made (did you know it uses a hard drive with perpendicular bit recording, which increases data density?). When a spam filter blocks something, I want to know how it works (did you know some of the most efficient ones are based on Bayesian statistical algorithms?). When I install an operating system, I need to know exactly how it works (did you know your new hardware supports DEP protection, but it’s probably disabled on your Windows? By the way, has anyone stopped to find out what DEP is?). When I use someone else’s network, I want to be sure nobody will spy on what I’m doing (have you ever used an external SSH server to create dynamic tunnels?). When I buy a new TV, I want to get the most out of it (has anyone here bought a plasma TV and hooked an antenna up to it? Or worse: plugged the DVD player in with a composite cable and can’t figure out why the picture is so bad?).

And these things aren’t just bar-talk curiosities. I read a lot, nearly 100 feeds on the most diverse subjects. Over 100 posts an hour, every day. Plus dozens of podcasts and a bunch of books, printed or PDF. And I still think it’s not enough. A certification whose only merit is one more line on your resume is the same as nothing. I still stand by the principle that professionals who genuinely love what they do (and show it by learning more and more) will never be out of a job. The ones who start from the goal of making money, ironically, will have the hardest time getting it.