Daily Reading for 2026-10-11
Daily Reading for 2026-10-11
Dwarf Fortress Version Control
Dwarf Fortress famously spent nearly two decades without version control, with Tarn Adams arguing that committing code into a “black box” offered no immediate upside. This note traces that stance from 2013 through 2016 to a 2023 admission that the project now uses version control and Discord channels as part of a more involved process. It matters because it shows even deeply idiosyncratic, long-lived codebases eventually converge on standard engineering practice when commercial scale and collaboration arrive — a case study in inertia finally giving way to evolution.
Watch for:
- Whether Dwarf Fortress’s version-control history becomes public or stays a private black box.
- Other long-lived indie codebases migrating onto standard tooling after commercial success.
- How the Steam-era team scales collaboration, release cadence, and contributor onboarding.
Wardley signals:
-
Components: the Dwarf Fortress codebase, version control (Git), Discord team communication, and Steam distribution.
-
Evolution stage: Git is Commodity (ubiquitous, standardised, utility-like); the Dwarf Fortress codebase is Custom (bespoke simulation built over decades); Discord is Product/Commodity (widely adopted team chat); Steam is Product (mature distribution platform).
-
Doctrine hits/misses: “Use standards” and “Use appropriate tools” were historically missed, now being adopted; “Manage inertia” is the central lesson, since success bred a two-decade resistance to standard practice.
-
Climatic patterns: “Success breeds inertia” and “Everything evolves through supply and demand competition”; the Steam milestone is the demand shock that forced the change.
-
Diffusion markers: late adoption of standard tooling driven by commercial success — an amateur-era workflow professionalising under growth.
wardley-beta %% 1. Users: indie game developers maintaining a long-lived simulation codebase %% 2. Needs: preserve decades of code history while shipping and collaborating %% 3. Capabilities: source history, team coordination, and distribution %% 4. Components: dwarfFortressCodebase, versionControlGit, teamChatDiscord, steamDistribution, releasePipeline %% 5. Maturity: Git/Steam are mature; the bespoke simulation and its pipeline are Custom %% 6. Management: Bay 12 Games (Tarn and Zach Adams), moving from ad-hoc to standard tooling anchor gameDeveloper [0.9, 0.92] component dwarfFortressCodebase [0.25, 0.62] component versionControlGit [0.8, 0.5] component teamChatDiscord [0.72, 0.4] component steamDistribution [0.68, 0.58] component releasePipeline [0.5, 0.38] dwarfFortressCodebase -> gameDeveloper versionControlGit -> dwarfFortressCodebase teamChatDiscord -> gameDeveloper steamDistribution -> gameDeveloper releasePipeline -> steamDistribution evolve versionControlGit 0.85
Python 3.15 in GitHub Actions
A small but practical link-blog note: Python 3.15.0 has landed in the actions/python-versions repository, meaning “3.15” can now be added to a GitHub Actions test matrix to run CI against the new release. Simon had been watching closely, even scripting ChatGPT to poll the repo hourly. It matters to technical readers because it marks the moment a new Python version becomes cheaply testable in the most common CI environment — the point where early adopters shift from curiosity to routine compatibility work and the wider ecosystem starts catching up.
Watch for:
- Third-party libraries publishing 3.15-compatible wheels, classifiers, and CI jobs.
- The Python 3.15 timeline moving from the current release toward a final, stable cut.
- Projects adding “3.15” to their matrices and surfacing the breakages that follow.
Wardley signals:
-
Components: Python 3.15, the actions/python-versions repository, GitHub Actions test matrices, and the PyPI/wheel ecosystem.
-
Evolution stage: Python itself is Commodity (universally accepted, standard language); GitHub Actions is Product/Commodity (mature CI utility); actions/python-versions is Product (a curated version-distribution service); 3.15 is Custom/early-Product (new release, still being adopted).
-
Doctrine hits/misses: “Use standards” (standardised CI version distribution) and “Bias towards the new”/“Bias towards action” (testing early against the new release) are illustrated.
-
Climatic patterns: “Everything evolves through supply and demand competition”; “Efficiency enables innovation” (cheap CI testing lowers the cost of compatibility work); “Components can co-evolve” as the language and its tooling advance together.
-
Diffusion markers: standardised version distribution plus fast ecosystem-wide CI matrix adoption, the classic pattern of a new release diffusing through tooling.
wardley-beta %% 1. Users: Python developers running CI on GitHub %% 2. Needs: test code against the newest Python release cheaply %% 3. Capabilities: a curated interpreter version and a runnable CI matrix %% 4. Components: ciTestMatrix, python315, actionsRunner, pythonVersionsRepo, pypiWheels %% 5. Maturity: Python/PyPI are Commodity; 3.15 is Custom/early-Product; CI tooling is Product %% 6. Management: GitHub maintains Actions and the version repo; the Python ecosystem supplies packages anchor pythonDeveloper [0.9, 0.92] component ciTestMatrix [0.55, 0.6] component python315 [0.32, 0.58] component actionsRunner [0.75, 0.5] component pythonVersionsRepo [0.6, 0.42] component pypiWheels [0.85, 0.38] ciTestMatrix -> pythonDeveloper python315 -> ciTestMatrix actionsRunner -> ciTestMatrix pythonVersionsRepo -> actionsRunner pypiWheels -> python315 evolve python315 0.45