I open-sourced my blog content 🔗 **Source:** [I open-sourced my blog content](https://dri.es/i-open-sourced-my-blog-content) > [!note]+ Document Notes > ```markdown > > --- > tags: [open-source, digital-preservation, blogging] > author: Dries Buytaert > source: dri.es > reference: [https://dri.es/i-open-sourced-my-blog-content] > date created: 2025-12-15 12:00 > > --- > > # 🏷️ Title: I open-sourced my blog content > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Include links cited in or relevant to the article. ## 📝 Summary - Dries exports ~20 years of blog posts to Markdown and publishes them in a public GitHub repo, auto-committed daily from his Drupal site. - It matters as an experiment in long-term digital preservation: reducing dependence on domains, hosting, and private backups. - Stakeholders: Dries, his readers, web historians/archivists, and other independent publishers. - Risks/tradeoffs: privacy of “deleted” content, potential misuse, reliance on GitHub and Git ecosystems. - Bottom line: treat personal websites like open-source code—versioned, clonable, and shared to increase their odds of surviving centuries. ## 📖 Main Content - Core idea: preserving a personal website for “hundreds of years” requires more than traditional backups. Websites are fragile because they depend on ongoing payments and maintenance; miss either and they vanish quietly. - Dries’ first step is to export all blog content as Markdown and push it to a public GitHub repository (`github.com/dbuytaert/website-content`). The site still runs on Drupal; this is an additional preservation and transparency layer. - He makes two explicit bets: - GitHub hosting is more likely to persist than his personal infrastructure or payment habits. - Public Git repositories can be cloned; each clone becomes an independent, self-sufficient copy. - This differs from typical static-site setups because most content repos are private. Making the content repo public exposes all changes: new posts, tag edits, and even posts he deletes. - Philosophically, he elevates publish, edit, and delete as equally legitimate actions—and now all three are visible in Git history. - He hints at a broader plan: “RAID 5 for public content” by spreading redundant copies across multiple systems, to be explained in a follow-up post. - Uncertainties: long-term survival of GitHub, whether clones will be created and maintained, and how future tools will interpret Markdown and Git history. ### 🗒️ Notes - “How do you preserve a website for hundreds of years?” is the guiding question. - Historical contrast: clay tablets and hand-copied manuscripts “asked very little of the future,” while websites require active care and money. - Traditional backups are not enough; they depend on someone knowing they exist and how to restore them. - Solution step 1: export all content to Markdown and push to a public GitHub repository on a daily schedule. - Site architecture remains Drupal-powered; GitHub is a content mirror/preservation layer, not a migration to static. - The public repo reveals: - New content as it’s published. - Edits over time (version history). - Deletions, because Git “hides nothing.” - Dries frames all three buttons—publish, edit, delete—as equally valid parts of authorship, now permanently recorded. - He anticipates a multi-system redundancy strategy (“RAID 5 for public content”), implying future distribution beyond GitHub. ## 📚 References - “I open-sourced my blog content” – Original article: https://dri.es/i-open-sourced-my-blog-content - Dries’ content repository: https://github.com/dbuytaert/website-content - Drupal (Dries’ CMS): https://www.drupal.org/ - Example static site generators (for contrast): https://jekyllrb.com/ | https://gohugo.io/ ## 🗣️ Paraphrase - Paragraph A paraphrase. - Websites are fragile compared to ancient media like clay tablets; to preserve his 20-year-old blog for centuries, Dries is experimenting with new strategies. - Paragraph B paraphrase. - He exports all posts to Markdown, publishes them in a public GitHub repo with daily auto-commits, exposing every publish, edit, and delete, and plans to add RAID-like redundancy later. ## 📰 Newsletter Hey folks, Neat preservation idea from the Drupal world that’s just as relevant to WordPress: Dries Buytaert has open-sourced 20 years of blog content by exporting it to Markdown and pushing it to a public GitHub repo with daily commits. Think of it as treating your blog like open-source code—versioned, clonable, and resilient. If you’re running WordPress, you could explore similar flows with export-to-Markdown plugins, Git-based workflows (e.g., using WP-CLI + cron), and static mirrors. This pairs nicely with modern deployment setups (GitHub Actions, Netlify, etc.) and long-term archiving strategies. Worth pondering: what would it take for your WordPress content to be readable in 100 years? ## ✅ Action Items #### DevRel - Outline a demo showing a CMS (including WordPress) exporting content to Markdown and pushing to a public Git repo for preservation. - Create a workshop on “Treating content like code” with hands-on Git workflows for writers. - Improve DX for content-in-Git: example repos, templates, and scripts for auto-commits from CMSs. - Write developer-focused posts comparing Drupal/WordPress approaches to versioned content stores. - Run a survey on how developers currently back up and archive personal and project sites. #### OSPO - Document guidance for projects encouraging open content mirrors (licenses, privacy implications, archival intent). - Ensure licensing is explicit when content is mirrored publicly (e.g., CC-BY, CC-BY-SA). - Integrate content repositories into SBOM and inventory processes where applicable. - Add training around compliance and copyright risks of publishing historical content (including “deleted” posts). - Explore partnerships with archival organizations (e.g., Internet Archive) for mirrored public projects. #### Community - Host a discussion on sustainable personal-site preservation and share best practices. - Support maintainers in documenting export formats (Markdown, JSON) and stable schemas. - Encourage “first issue” tasks around documentation and tooling for archival/export features. - Share transparent community budgets for preservation initiatives and infrastructure. #### WordPress - Core: explore better structured content export capabilities (including Markdown or well-documented JSON). - Core Performance: consider how static mirrors and Git-based workflows can reduce dynamic load. - Core AI: evaluate AI tooling for summarizing/versioning long-running blogs safely and ethically. - **Core Program Team:** coordinate cross-team conversations about content export, versioning, and long-term storage. - Mobile: investigate offline-readable archives and export options from mobile apps. - Playground: provide labs for experimenting with Git-based WordPress content workflows. - Community: add content-preservation topics to meetups and WordCamps. - Training: create lesson plans around backups, exports, and Git workflows for content creators. - Marketing: tell stories of long-lived WordPress sites and how they stay preserved. - Support: ensure docs cover both backups and export/mirroring strategies. - Design: explore UI patterns that make export and archival options discoverable and understandable. - Documentation: expand HelpHub/DevHub coverage on exporting, versioning, and archiving content. - Photos: consider preservation-friendly export options for media libraries. - TV: record sessions on “Archive-friendly WordPress” best practices. - Polyglots: highlight how translation content can be exported and preserved. - Accessibility: ensure export formats keep text accessible and machine-readable. - Meta: investigate .org-level tools for content export and archival aid for community sites. - CLI: enhance WP-CLI commands for exporting posts/pages in archive-friendly formats. - Hosting: collaborate on default backup + export bundles that are easy to restore or clone. - Tide: consider preservation/maintainability signals for plugins that manage content. - Openverse: ensure licensing and attribution are preserved in long-term archives. - Themes: encourage themes that don’t obscure or lock in content structures. - Plugins: promote plugins that support open, portable, and archival content formats. #### The WPOCC - Programs: pilot microgrants for projects improving content export and archival workflows. - Projects: host documentation sprints focused on long-term preservation practices. - Funding experiments: support community-run mirrors or archival infrastructure for critical resources. ### FAIR - Promote technically independent content archives (local copies, signed snapshots). - Encourage transparent funding/governance for preservation infrastructure. - Develop reusable governance artifacts for community-run archives. ## 🧪 Hypotheses - Public Git repositories meaningfully increase the likelihood that personal-site content survives beyond the original owner’s hosting. - Auto-committing CMS content to a public repo reduces the chance of total data loss compared to ad hoc backups. - Exposing full edit/delete history will change how some authors think about revisions and “deletion.” - Multi-system “RAID-style” redundancy for public content will be more resilient than any single hosting provider. ### 📊 Methodology - Compare survival rates of sites with public Git mirrors vs. sites without mirrors over a multi-year period. - Survey/blog analysis of creators who adopt Git-based content workflows to assess behavior changes around editing/deleting. - Build a prototype “RAID 5 for content” system, simulate provider failures, and measure recovery success. - Analyze restoration timelines and completeness from Git archives vs. traditional backups when sites go offline. ### ❓ Questions - Will enough people clone the repo for redundancy to actually matter? - How might future tools interpret and render today’s Markdown and metadata? - What ethical considerations arise from preserving “deleted” posts in public history? - How can non-technical authors benefit from this approach without learning Git? ### 🔮 Future Research - Standardizing a “preservation-ready” export format across CMSs. - Exploring decentralized storage (IPFS, Dat) as complements to GitHub. - Governance models for community-maintained mirrors of personal or small-org sites. - Tools that reconstruct full sites (themes, media, structure) from content-only archives. ### 💡 Implications - Practice: independent publishers may start treating content like code with version control and public mirrors. - Policy: organizations might adopt explicit content-retention and archival policies, including open repositories. - Security: public history of deletes/edits requires careful consideration of sensitive data. - Education: curricula for web literacy may begin to include archival design and Git for non-developers. - Funding: preservation infrastructure could become a recognized public good worth funding. ### 🧠 Learning Styles Assessment - Reading level estimate: roughly 9th–10th grade (Flesch-Kincaid style; short, clear sentences, limited jargon). #### 👀 Visual learners - Present: mainly text, simple narrative; no diagrams. - Improve: add diagrams of the current system (Drupal → export → GitHub) and envisioned “RAID 5” architecture. #### 🔊 Aural learners - Present: no audio. - Improve: short audio or podcast-style explanation about digital preservation choices. #### 🗣️ Verbal learners - Present: clear prose, analogies to clay tablets and medieval manuscripts. - Improve: glossary of terms (Markdown, Git, RAID) and more examples of alternative setups. #### 🧩 Kinesthetic learners - Present: implicit “how-to” idea but no steps. - Improve: provide a step-by-step guide for replicating the export-to-GitHub workflow. #### 🧠 Logical learners - Present: causal reasoning (backups vs. Git, hosting fragility vs. redundancy). - Improve: tables comparing strategies (traditional backups vs. Git vs. multi-site redundancy). #### 🧑‍🤝‍🧑 Social learners - Present: implicit invitation to think along with the author over the next 10 years. - Improve: discussion prompts or calls for collaboration on shared archival tooling. #### 🧘♀️ Solitary learners - Present: reflective narrative suitable for personal contemplation. - Improve: explicit reflection questions about one’s own website preservation strategy. #### 🌿 Naturalistic learners - Present: no explicit environment/sustainability tie-ins. - Improve: analogies to ecological resilience (e.g., diversity of habitats ~ redundancy of storage). ### 📊 Accessibility Assessment #### Screen reader semantics - Present: likely basic HTML article structure (headings, paragraphs). - Improve: ensure robust heading hierarchy and descriptive alt text for any future diagrams. #### Keyboard navigation - Present: standard blog layout likely keyboard-usable. - Improve: confirm skip links, visible focus states, and logical tab order. #### Contrast and readability - Present: typical dri.es design; likely adequate contrast and readable fonts. - Improve: verify contrast ratios and line-height for long-form reading. #### Text resizing and reflow - Present: responsive blog, likely reflows reasonably. - Improve: test up to 200% zoom and support for reduced motion preferences. #### Media and captions - Present: text-only article. - Improve: if adding media, provide captions and transcripts. #### Forms and interactions - Present: minimal; likely just navigation and comments. - Improve: ensure any forms have clear labels and error messages. #### Standards reference - Map any gaps against WCAG 2.2 AA, especially 1.4 (distinguishable), 2.1 (keyboard), 2.4 (navigable), and 3.3 (input assistance). ### 🌍 DEIB Assessment #### Cultural breadth - Present: examples focused on Western historical artifacts (medieval monks, Mesopotamia). - Improve: include more diverse historical preservation practices. #### Inclusive language - Present: neutral, accessible language overall. - Improve: define technical terms more explicitly for non-experts. #### Neurodiversity support - Present: clear structure, short paragraphs. - Improve: more subheadings, summaries, and predictable patterns for long-term series. #### Representation - Present: first-person account; no imagery or other representation. - Improve: when adding visuals, ensure diverse and inclusive imagery. #### Psychological safety - Present: non-triggering, reflective tone. - Improve: provide clear contact or feedback channels for questions or concerns about archived content. ### ✅ Logical Validity #### Strong reasoning - Inductive/causal: “Websites require continuous maintenance and recurring payments. Miss either, and they quietly disappear.” This is grounded in common experience and motivates the backup strategy. - Analogical: comparing clay tablets and handwritten manuscripts to modern websites highlights why low-dependency media last longer. #### Fallacies - None obvious; the argument is presented as an experiment, not as a universal proof. #### Tone of voice - Thoughtful, exploratory, slightly technical but approachable. The author is transparent about uncertainty and future plans (“I don't have the answer yet...”). ### 🛡️ DARVO Analysis - Deny: no denial of responsibility; he acknowledges limitations of current approaches. - Attack: no attacks on others; tone is non-confrontational. - Reverse victim/offender: not applicable; the piece is about technology and preservation, not interpersonal conflict. ## 🎯 Conclusion Dries is experimenting with a practical first step toward long-term web preservation: exporting his 20-year blog history to Markdown and open-sourcing it on GitHub with automated updates. By making the repo public and planning RAID-style redundancy across systems, he aims to increase the odds that his website—and by extension, similar sites—can outlive their current infrastructure. Next steps for readers: assess how your own content is backed up, how portable it is, and whether a Git-based mirror could improve its resilience. ## 🧱 Refactor Appendix (append after 🎯 Conclusion) ### 📚 Literature Split Pad - Purpose: Stage Konik CEE units that become per-source Literature notes. - Split level: **H3**. - Include verbatim quotes under 25 words and a [view highlight] link. ### [H1] 5–10-word present-tense claim > [!quote] [I open-sourced my blog content](https://dri.es/i-open-sourced-my-blog-content) by [[Dries Buytaert]] via [[dri.es]]. Published 2025-12-15. Accessed . > “I exported my blog as Markdown files and put them on GitHub.” Two lines: context and use. Cite data if relevant. [view highlight](https://dri.es/i-open-sourced-my-blog-content#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] 5–10-word present-tense claim > [!quote] [I open-sourced my blog content](https://dri.es/i-open-sourced-my-blog-content) > “For the past two weeks, my site has been auto-committing to GitHub daily.” Two lines: context and use. [view highlight](https://dri.es/i-open-sourced-my-blog-content#H2) #xref ID:rw_[MISSING] --- ### 🔖 Atomic Split Pad (Zettel Candidates) - Purpose: Promote reusable claims into Atomic notes. - Split level: **H4**. - Each item: one idea, present tense, specific, testable. #### [Z1] Public Git mirrors improve content durability - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[Digital-Preservation]] [[Content-as-Code]] #### [Z2] Content exports reduce dependency on live CMS - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[CMS-Architecture]] [[Archival-Design]] --- ### ✏️ Fleeting Queue (Extract by Selection) - Purpose: Capture quick actions or sparks for Fleeting notes. - Extraction: **Select one line** → “Refactor: Extract selection to new note (content only).” - Keep each line short and self-contained. - [F1] Prototype a WordPress-to-Markdown-to-GitHub auto-commit workflow—context/https://dri.es/i-open-sourced-my-blog-content #fleeting #inbox - [F2] Draft a talk on “RAID 5 for public content” for WordCamp—context/https://dri.es/i-open-sourced-my-blog-content #fleeting #inbox - [F3] Research ethical guidelines for preserving deleted content publicly—context/https://dri.es/i-open-sourced-my-blog-content #fleeting #inbox --- <!-- deep-read:sections end -->