Ferrum is the name I use for a growing family of developer-tool and systems projects. The shared name reflects a shared direction: Rust-focused tools, local-first workflows, explicit behavior, and an emphasis on software that is pleasant to reason about.
That shared identity creates an architectural temptation. If several projects follow the same principles and may eventually work together, it can seem natural to combine them into one application. One command could scaffold a project, define its language, build its output, manage its repository, and provide the environment in which all of that work happens.
I do not think that would make Ferrum stronger. I think it would make each part harder to understand.
Ferrum should be an ecosystem of focused tools, not a platform that must own the entire workflow.
One recognizable problem at a time
A useful boundary begins with a sentence: this project solves this problem.
The sentence does not need to describe a tiny problem, but it should identify one coherent responsibility. A developer should be able to understand why the tool exists, decide whether it fits, and adopt it without first learning the architecture of everything around it.
That clarity helps users, but it also disciplines the design. When a feature does not belong to the project’s central responsibility, the boundary creates a reason to move it elsewhere, postpone it, or decide that it is not needed. Without that pressure, related ideas accumulate until the original tool becomes a container for every nearby problem.
Small tools are not automatically well designed. They can still have confusing interfaces or overlap in arbitrary ways. The advantage is that a strong boundary makes those problems easier to see.
Boundaries make change safer
Focused projects are easier to understand, test, replace, and abandon.
That last quality matters. Experiments should be allowed to fail without taking an entire environment with them. If a scaffolding approach turns out to be wrong, replacing Ferroforge should not require redesigning Feo. If the boundary between Feo and Ferrisle changes, it should not invalidate a repository workflow. Each project can mature at its own speed because its internal decisions do not automatically become ecosystem-wide commitments.
This also keeps early projects honest. Ferrum includes tools at very different stages: some have working code, some are active design and implementation efforts, and others are long-term directions. Calling them an ecosystem does not mean presenting them as a finished suite. It means designing their relationships so that one project does not need to pretend the others are complete.
Composition should be optional
The projects can work together without requiring one another everywhere.
Feo is the language layer: a DSL for describing static pages, components, content references, styles, and optional browser behavior. Ferrisle is the site-building layer that may use Feo to produce plain, deployable websites. Keeping those names and responsibilities separate leaves room for the language and the builder to develop without becoming synonyms.
Ferroforge addresses project creation through practical, repeatable scaffolding. It may eventually know how to create a Feo or Ferrisle project, but it should remain useful for other project types. Ferrule is planned around project checkpointing and Git-based save workflows. Its value should not depend on which language or generator produced the files it saves.
Ferrost and Ferrostide explore a larger working environment intended to reduce context switching among the terminal, editor, and AI tools. That direction could eventually integrate several Ferrum projects, but integration should not turn those projects into private subsystems that only make sense inside Ferrost.
Other projects sit even farther from the main path. Oxidelve is a system-information and image-conversion CLI. Ferrux-grid explores testable workspace layout, while Ferrux is a much longer-term systems direction. A shared design philosophy can connect them without inventing runtime dependencies they do not need.
A developer should be able to adopt one Ferrum tool and ignore the rest.
Local-first tools keep the relationship visible
Strong boundaries are easier to preserve when the tools meet through ordinary artifacts: files, directories, command-line interfaces, and documented output.
Plain files keep ownership with the user. They can be inspected with familiar tools, committed to a repository, generated by something else, or edited by hand. A command that accepts a path and produces an understandable result is easier to replace than a feature that depends on hidden state inside a shared service.
Local-first does not mean rejecting every service or integration. It means the primary workflow should remain understandable from the user’s machine and files. Integration can add convenience without becoming the only way the pieces communicate.
That reduces lock-in at two levels. Users are not forced to adopt the whole ecosystem, and individual Ferrum projects are not forced to preserve an internal dependency merely because another project once relied on it.
Some boundaries are still unresolved
The clean diagram is not the goal. The useful separation is.
Feo and Ferrisle are the clearest example of a boundary that still needs testing. Feo should define the language and its meaning. Ferrisle should handle the work of building a site. But decisions about project structure, asset handling, content loading, development servers, and output coordination can sit near that dividing line. The right answer will come from building and using both, not from defending the first architecture I draw.
The same caution applies to Ferrost and Ferrostide. Reducing context switching is a broad goal, and broad goals can absorb almost anything. Those projects will need especially strong boundaries if they move from exploration into implementation.
Being candid about that uncertainty is part of the design. A boundary should be strong because it has survived contact with real workflows, not because it was named early.
An ecosystem is a promise about independence
For me, calling Ferrum an ecosystem is not a claim about scale. It is a statement about how the projects should relate.
They can share a visual identity, a language of design, and a bias toward predictable local tools. They can provide smoother workflows when used together. But no project should require allegiance to the full set, and no central application should become the only place where the parts remain useful.
The measure of the ecosystem will not be how tightly everything connects. It will be whether each tool can stand on its own, compose where the connection is valuable, and remain replaceable when a better answer appears.
That is the kind of relationship I want Ferrum to represent: shared principles, optional integration, and boundaries strong enough to let every project become what it needs to be.