DocsHub — Version Wombat

The foundation of the next generation of the ZFordDev documentation ecosystem.

Version Wombat is more than a redesign of DocsHub.

It is the beginning of a fundamental architectural shift in how documentation is created, organised, published, discovered, maintained, and eventually shared across the ZFordDev ecosystem.

Wombat is the point at which DocsHub stops being a collection of documentation pages and starts becoming a documentation platform.

It is also part of a much larger change across the ecosystem: moving projects from purely hobby-driven software toward sustainable products while keeping their core technology accessible, usable, and self-hostable.

Wombat is therefore not a finished release in the traditional sense.

It is a living architectural generation.

The system will continue to evolve as new requirements are discovered, new projects join the ecosystem, and real-world usage exposes weaknesses in the architecture.

What Is Wombat?

Wombat is the architectural generation of DocsHub responsible for building the infrastructure that connects the documentation ecosystem together.

The previous generation of DocsHub was primarily concerned with displaying documentation.

Wombat is concerned with everything around that documentation:

• how projects identify themselves
• how documents describe themselves
• how content is indexed
• how documentation is discovered
• how versions are represented
• how projects are grouped
• how different documentation hubs communicate
• how authors eventually create and publish content
• how the system can scale beyond a single developer
• and how the entire platform can remain useful without becoming dependent on a hosted service

The goal is not simply to make DocsHub look better.

The goal is to make the underlying system correctly structured enough that the interface can continue evolving without requiring the entire platform to be rebuilt again.

Wombat Is an Architectural Milestone, Not a Final Version

One of the most important things to understand about Wombat is that it is not expected to be complete for a long time.

Wombat represents the direction of the platform rather than a single completed feature set.

Some components may be considered stable while others remain experimental. Some planned systems may not exist yet. Others may be replaced entirely as the architecture develops.

This is intentional.

A documentation platform used by multiple projects has a very different set of requirements from a small documentation website.

Building every feature before real usage would mean designing around assumptions rather than evidence.

Wombat therefore follows an iterative approach:

Build the foundation → use it → discover the weakness → improve the architecture → repeat.

The milestone is named, documented, and versioned so that this evolution can remain understandable even while the implementation continues changing.

The Problem Wombat Exists to Solve

The original DocsHub architecture grew organically.

That was appropriate for a hobby ecosystem.

Individual projects could maintain their own documentation, metadata, layouts, and search behaviour without needing a larger system to coordinate them.

As the number of projects increased, however, this approach began producing duplication and fragmentation.

Documentation became increasingly difficult to search across projects.

Shared functionality had to be implemented multiple times.

Metadata was not consistently structured.

Search relied heavily on manually maintained JSON data.

Adding a new project could require changes in places that should have been completely independent of one another.

The system worked.

But it did not scale cleanly.

Wombat exists to address that architectural problem.

1. Unified Documentation Architecture

Wombat brings the documentation ecosystem under a common architectural model.

Projects can still maintain their own identities and documentation structures, but the underlying platform understands them through shared metadata and common interfaces.

This allows DocsHub to treat documentation as an ecosystem rather than a collection of unrelated websites.

The architecture provides common foundations for:

• project identification
• document metadata
• categories
• tags
• versions
• layouts
• navigation
• indexing
• search
• cross-project references
• documentation relationships
• publishing
• future authoring systems

This means a project can remain independent without requiring the platform around it to be reinvented.

2. Metadata Becomes Infrastructure

One of the major principles of Wombat is that metadata should describe the content rather than requiring the platform to know about every page manually.

A document should be able to declare what it is.

For example:

project: standards
module: docshub
category: explanation

title: "Release Architecture: Version Wombat"

tags:
  - docshub
  - architecture
  - wombat

weight: 1
context_priority: high

This information can then be consumed by different parts of the platform.

The same metadata can potentially drive:

• navigation
• search
• project indexes
• category pages
• related documentation
• version filtering
• homepage generation
• recommendations
• cross-project relationships

The important distinction is that DocsHub should not need a special rule for every new document.

The document should describe itself.

3. Version-Aware Documentation

Documentation becomes increasingly difficult to maintain as software evolves.

A page that is correct for one version may be incomplete, misleading, or completely wrong for another.

Wombat introduces version awareness as a first-class part of the documentation architecture.

Documents can declare the versions, releases, or compatibility contexts they belong to.

This allows DocsHub to eventually answer questions such as:

• Which documentation applies to this version?
• Is this guide outdated?
• What changed between releases?
• Which version introduced this feature?
• Is this documentation still supported?
• Are there newer instructions available?

Version awareness is therefore not simply a visual filter.

It is intended to become part of the underlying information architecture.

4. Search Is Being Rebuilt

The previous DocsHub search system relied heavily on manually generated JSON data.

It was functional, but it required maintenance and lacked the intelligence expected from a modern documentation portal.

Wombat replaces that approach with a search architecture designed around the actual structure of the documentation.

The intended system includes:

• fuzzy matching
• contextual weighting
• metadata-aware searching
• project filtering
• category filtering
• version filtering
• tag matching
• cross-project discovery
• relevance ranking
• related-content discovery

The objective is not simply to find pages containing a matching word.

The objective is to find the most relevant documentation.

A search for a concept should therefore be capable of discovering useful documentation even when the exact phrase entered by the user does not appear in the title.

5. DocsHub Becomes a Platform

Wombat changes the role of DocsHub.

It is no longer intended to be merely:

“The website where ZFordDev documentation lives.”

Instead, DocsHub is becoming infrastructure that can support documentation for an entire ecosystem.

That includes the possibility of documentation for:

• ZFordDev projects
• community projects
• standards
• tutorials
• technical references
• third-party projects
• future hosted customers

The long-term objective is for the same underlying platform to be capable of powering documentation outside of the ZFordDev ecosystem itself.

6. Self-Hosting Is a Core Principle

DocsHub is not intended to become a platform where hosting is mandatory.

The software should remain capable of being deployed independently.

If someone wants to host their own documentation infrastructure, they should be able to do so.

This is important because the underlying software should remain useful even without a commercial relationship with ZFordDev.

The architecture is therefore being designed around a simple principle:

Hosting is a convenience, not a requirement.

A user should be able to take the software, build their documentation, and host it themselves.

The hosted version exists to remove that work.

7. Open Core and Sustainable Software

Wombat is also part of a broader change in the ZFordDev ecosystem.

For a long time, many projects were built primarily as hobby software.

That model is excellent for experimentation, but it is difficult to sustain indefinitely.

Servers cost money.

Development takes time.

Infrastructure requires maintenance.

Documentation requires continual work.

Support takes time.

A sustainable ecosystem therefore needs a way to generate revenue without putting the core technology behind an artificial paywall.

The emerging model is intentionally simple:

The core software remains accessible.

Users who want to operate the system themselves should be able to.

Users who want convenience can pay for hosted services.

Instead of charging simply for permission to use the software, the commercial offering provides value through things such as:

• managed hosting
• infrastructure
• maintenance
• updates
• convenience
• reduced operational overhead
• potentially additional hosted services

This creates a relationship where paying customers are primarily paying to avoid work, rather than paying to unlock the fundamental ability to use the software.

8. Hosted DocsHub

The long-term commercial model for DocsHub is therefore not:

“Pay us or you cannot use DocsHub.”

It is:

“You can host DocsHub yourself, or we can host it for you.”

Self-hosting provides control.

Hosted DocsHub provides convenience.

Both are legitimate ways of using the platform.

This distinction is important to the philosophy of the ecosystem.

The goal is to build software that remains useful even if a user never becomes a customer.

At the same time, users who choose hosted services should provide enough recurring revenue to make continued development, infrastructure, maintenance, and support sustainable.

9. SnapDock and DocsHub

Wombat also lays the groundwork for a closer relationship between DocsHub and SnapDock.

Documentation should not require an awkward separation between writing and publishing.

The long-term vision is for SnapDock to become part of the authoring workflow:

Write → organise → preview → publish → index → discover.

A future authenticated portal could allow authors to work with their documentation online while DocsHub handles the publishing and discovery side of the system.

This could eventually support:

• authenticated authors
• document editing
• drafts
• publishing
• revision history
• project permissions
• collaborative documentation
• publishing directly into DocsHub

These systems are not all part of the current Wombat implementation.

They are part of the architectural direction Wombat is being built to support.

10. From Projects to an Ecosystem

Wombat exists alongside a wider naming and architectural change across ZFordDev.

As the ecosystem grows, projects are increasingly being given names rather than being identified purely through version numbers or technical labels.

This is partly practical.

Named projects are easier to discuss, remember, document, and distinguish from one another.

But it is also intentional.

Software projects are built by people, used by people, and maintained by people.

Giving systems names creates identity.

A project becomes more than:

v3.2.1

It becomes something people can actually refer to.

Wombat is part of that philosophy.

The name represents a specific architectural generation while giving the system an identity independent of its current implementation.

Why “Wombat”?

Why Wombat?
The wombat — native to Australia — is known for building and maintaining complex tunnel networks. That makes it an appropriate metaphor for this release: Wombat is about constructing the infrastructure, pathways, connections, and foundations underneath everything else.

A documentation platform is mostly invisible when it works correctly.

Users see pages.

They do not see the indexing system.

They do not see the metadata pipeline.

They do not see the build process.

They do not see the relationships between projects.

They do not see the architecture connecting everything together.

Wombat is therefore the infrastructure underneath the visible documentation experience.

The tunnels matter even when nobody sees them.

What Wombat Enables

The architecture is intended to enable:

• a single DocsHub homepage populated from project metadata
• automatic project discovery
• category-based organisation
• shared UI components
• unified metadata
• version-aware documentation
• intelligent search
• fuzzy matching
• contextual relevance
• cross-project linking
• related-document discovery
• consistent authoring through SnapDock
• future authentication
• future collaborative authoring
• self-hosted deployments
• managed hosted deployments
• future customer documentation portals
• a common foundation for the wider ZFordDev ecosystem

Not all of these capabilities exist today.

That distinction matters.

Wombat is the architecture being built to make them possible.

What Wombat Is Not

Wombat is not intended to become a proprietary documentation silo.

It is not designed around mandatory cloud hosting.

It is not intended to require a subscription simply to read or create documentation.

It is not a promise that every planned feature already exists.

And it is not a finished product.

Wombat is an evolving platform.

The architecture will change when real-world requirements prove that it needs to change.

The Long-Term Direction

The eventual goal is larger than DocsHub itself.

DocsHub is becoming one component of a connected ZFordDev ecosystem in which projects can share infrastructure without losing their independence.

A user should be able to discover a project, read its documentation, find related projects, follow a tutorial, inspect a standard, and eventually create or contribute documentation without having to understand how all of those systems are implemented underneath.

The complexity should live in the platform.

The experience should remain simple.

That is the purpose of Wombat.

Wombat Is Still Being Built

Wombat should be considered an active architectural generation rather than a completed product.

There will be changes.

There will be systems that are replaced.

There will be ideas that turn out to be unnecessary.

There will be features that become significantly more important than originally expected.

That is part of building the platform properly.

The objective is not to declare Wombat finished as quickly as possible.

The objective is to keep improving it until DocsHub becomes the documentation platform it is intended to be.

Wombat is the foundation.

The ecosystem built on top of it is the destination.

Current Status

Architecture: Active development
Search: Being rebuilt
Version awareness: In development
Unified metadata: Active
Self-hosting: Core principle
Hosted service: Long-term commercial direction
SnapDock integration: Planned / evolving
Multi-user authoring: Future
Wombat completion: No fixed completion date

Wombat will remain an evolving architecture for as long as the platform continues to grow.