This dispatch exists because of a news item I came across last week. I had better begin by crediting its source, since the dispatch would not otherwise exist. PetaPixel, on the seventh of October, reported that a software engineer named Brandon Thomas had, over the preceding twelve months, written and released clean-room reimplementations of seven of Adobe's Creative Cloud applications: Photoshop, Illustrator, Premiere, Lightroom, Acrobat, After Effects, and InDesign. The applications are open source, free of charge, published under the ArtCraft banner on GitHub, written in pure Rust, and shipped for macOS, Windows, and Linux (the last of which Adobe does not support at all). Mr Thomas, by his own account on Reddit, used Anthropic's Opus 5.5 to assist him; also by his own account, he is "not a casual vibe coder," but a fifteen-year industry veteran who has been writing Rust more or less daily for a decade.
I read this news on a Tuesday evening. By the Wednesday morning, the small corner of the world in which this journal is being written had, in the quiet way that these decisions sometimes make themselves, resolved to attempt the same thing. In our case the target is not creative software. The target is DHIS2, the Java platform on which more than seventy ministries of health run their routine data. The language is not Rust. The language is Go, which suits the shape of a data plane the way Rust suits the shape of a native desktop editor. The ambition is otherwise the same. The project has a working name: DHIS3/go. The journal you are reading exists to tell you how it goes.
What Mr Thomas has demonstrated
Mr Thomas has demonstrated three things, and I want to name them before I say what we take from them.
The first is that one determined engineer, in a modern language, with contemporary assistance, can now rebuild something large. "Clean-room reimplementation" is a technique that has been with the industry since at least Phoenix's rewrite of the IBM BIOS in 1983. It has, for most of that history, been so expensive and so slow that only a few companies could attempt it. Compaq reconstructed a BIOS. Lotus reconstructed a spreadsheet. No one reconstructed Photoshop. Jeremy Gray, writing for PetaPixel, put the shift precisely: "this legal framework was developed when reverse engineering software was so cost-intensive and time-consuming that undocumented code was itself a form of financial security. With the advent of AI, that is no longer the case." Reasonable people may disagree about what else is also no longer the case. We may agree, I think, that this part of it is.
The second is that the method still rewards the kind of hands that already knew how to work. The applications published under storytold/photocraft and its sibling repositories are not casual outputs. They carry proper Rust discipline. They inherit the file-format compatibility of their forebears. They ship for three operating systems. Mr Thomas's Rust background is the ground on which the AI tools do useful work; without that ground the result would be, in the classical phrase, vibes. This is a very old lesson rediscovered in a very new form. Novelty does not retire craft; it rewards it.
The third is that the method is now accessible to small teams in sectors that have historically been priced out of it. Which is where we come in.
Why DHIS3/go, and why now
DHIS2 is a serious piece of software maintained by HISP UiO in Oslo, carried in production in more than seventy countries, currently at version 43 as of the May 2026 release. It handles the routine data of malaria notifications, child immunisations, maternal deaths, and the ten thousand smaller numbers that, when the system works, inform a decision about which clinic needs more staff this quarter. It is a public good. I have no complaint about the choice its maintainers made to build it in Java fifteen years ago, which was the correct choice at that time.
What has changed is not the quality of DHIS2's craft. What has changed, this year, is the cost of attempting a reimplementation. HISP's recent release notes show a team that has shipped Apache Doris and ClickHouse support for analytics, moved the Capture app to TypeScript and React 18, upgraded to Hibernate 6, and continued to maintain the Global Shell and the plugin surface they introduced in v42. It is a serious road, well travelled. We are not proposing to displace it. We are proposing, as Mr Thomas has done for a different sector, to build a parallel implementation of the public interface, in a different language, in the open, under the same BSD 3-clause licence DHIS2 itself uses.
The reasons to attempt it are the reasons any sector gives for a reimplementation. Analytics performance at scale. An addon ecosystem closer to Odoo or Frappe/ERPNext than to today's DHIS2 app model. A Python contingent for the kinds of statistical and machine-learning work that are easier in Python than in Java. A chance to settle a few old architectural questions that no healthy maintenance team can be asked to open mid-flight. These are proper engineering reasons. They are not, by themselves, enough to justify the undertaking. What is enough is the moment: the cost of a serious attempt has fallen far enough that a small team can now attempt one.
What we take from Mr Thomas, specifically
We take, first, the method. One language in the core (Rust for him; Go for us). A clean-room reimplementation of the public interface, not a line-by-line translation of the proprietary source. File-format and API compatibility as the compatibility contract, so a user can switch without redoing their work. An open licence (he uses MIT; we follow DHIS2 upstream to BSD 3-clause). The expectation that modern assistance is the force multiplier, and the discipline of a seasoned engineer is the condition that lets it compound.
We take, second, the cadence. Mr Thomas has said he hopes to reach complete feature parity "within a month," which one Reddit commenter rightly calls "an ambitious target." We will make no such claim. Our sector is institutional; a tracker import of fifty thousand events must return the same numbers as the Java system to the row, and the mechanism by which we prove that will take as long as it takes. But the discipline of shipping is one we borrow directly: short, frequent, demonstrable, not a one-year silent build.
We take, third, the framing. Mr Thomas writes about the ArtCraft repositories on GitHub in the voice of a working engineer, not of a marketing department. We will attempt the same. There is no subscription here. There is no landing page with a hero image and a customer logo wall. There is a journal, kept intermittently by a correspondent of modest ambition, in a Twain-adjacent register.
What is different
Three things are different and worth saying out loud.
The first is the audience. The seven applications under storytold will be downloaded, used, cursed at, and praised by individual artists, photographers, filmmakers, and designers whose workflows have very low tolerance for change. Our audience is institutional. The people on the other end of DHIS3/go, when the day comes, will be health-ministry CIOs and the implementers and clinicians who use the system through them. They care less about pixel perfection and more about whether the Android Capture app still syncs cleanly against the new backend. The compatibility bar is different. It is not lower. It is just different.
The second is the shape of the compatibility problem. Photoshop's PSD format is well-documented and old. DHIS2's Web API is well-documented and old. Both are, in the engineer's phrase, the contract. But DHIS2 carries, in addition, the behaviours of a metadata-driven data model that users have configured over years, in production, in dozens of countries, and nobody has written down the full set of edge cases because nobody could. We will discover them, one at a time, by comparing what the old system does against what the new system does, for the same input. That is a long, patient business. The quiet piece of work ahead of us is building the harness that does the comparing.
The third is that nobody writes about this. The world is generally interested in a photo editor. The world is less generally interested in whether a public-health analytics endpoint returns the same multi-dimensional data grid under both the Java and the Go implementations. I accept that cheerfully. If this journal attracts five regular readers who care about the latter, I will consider myself vindicated.
What I take from it personally
I take, first, courage. Not the kind that pretends the work will be easy. The kind that quietly notes that something structurally similar has been done next door in an adjacent sector, by one determined person in a year, and therefore the question is not whether the undertaking is possible, but whether we are patient enough to carry it through.
I take, second, a reminder about the discipline. Mr Thomas's line about not being "a casual vibe coder" is one I propose to keep over my desk. The modern tools work best in hands that already knew how to work; we should carry on building, in our team, exactly those hands.
I take, third, the thought that the patent question is not quite as resolved as the engineering question. Patents are patents. The lawyers will have their say. We will stay in the gentle middle of the clean-room tradition, which is older than most of us, and let the lawyers argue when the argument needs arguing.
For now, the news of the workshop next door is itself the reason this dispatch exists. We would not be writing this journal, or indeed this project, had Mr Thomas not shown that the undertaking is possible for one person, in one year, in Rust. We will attempt the same in Go, for a very different kind of software, for a very different audience, with the gratitude due to anyone who demonstrates a thing before you have asked them to. I will raise a hand across the Mississippi, in the direction of wherever Mr Thomas keeps his workshop.
— Mulberry