An ecosystem of autonomous, free and interoperable services, designed to run first at its user's home, not at its vendor's.
Read in another language: English (this document) · Français.
The reference documentation itself lives in
docs/and is currently written in French.
This repository is the reference documentation of the morfSystem ecosystem.
If you are discovering the project, we recommend the following reading order:
- 📖 Getting started
- 📖 Philosophy — why the ecosystem is designed this way
- 📖 Architecture — how the pieces fit together
- 📖 Thinking in morfSystem
- 📖 Architecture principles
- 📖 Contracts
- 📖 Design decisions
- 📖 Decision framework
- 📖 Development rules
- 📖 Local data layout
- 📖 Governance
- 📖 Project lifecycle
- 📖 Contributing — how to take part, and the hard rules
- 📖 New-project checklist
- 📖 Ecosystem
- 📖 Glossary — the key terms at a glance
- 📖 Roadmap
- 📖 What morfSystem is not
- 📖 FAQ
morfSystem was not born from the wish to create a new platform, a new framework or a new software suite.
It was born from an observation.
Over the years, many personal projects appeared: supervision tools, connected sensors, desktop applications, network services, system utilities...
Each project answered a precise need.
Each project worked.
But each one reinvented part of the same mechanisms: network discovery, supervision, configuration, updates, communication between applications, deployment...
The simplest solution would have been to merge everything into a single application.
That choice was deliberately rejected.
Conversely, the current trend often consists of splitting applications into a multitude of tightly coupled microservices, to the point that none can really run on its own.
That choice was rejected too.
morfSystem was born between these two extremes.
The goal is not to build a platform.
The goal is to build a coherent ecosystem.
Each component has a clearly defined responsibility.
Each component remains usable on its own.
When they are present together on the same network, they collaborate naturally through shared contracts rather than through imposed dependencies.
This difference is fundamental.
morfSystem never forces one component upon you because another is installed.
It offers cooperation, never an obligation.
To understand the motivations behind this architecture, read the Philosophy.
morfSystem is a set of free software programs sharing the same design philosophy.
It is not a monolithic software suite.
It is not an operating system.
It is not a framework.
Each project has its own repository, its own development cycle, its own documentation and its own responsibility.
Components share only what genuinely needs to be shared:
- conventions;
- exchange contracts;
- documented protocols;
- a common philosophy.
Everything else belongs to each project.
This approach lets each component evolve without calling the whole ecosystem into question.
The overall organisation is presented in Architecture.
Understanding what morfSystem refuses is as important as understanding what it offers.
morfSystem is not a framework: it imposes no way of developing, only principles.
It is not a software suite: you install only the components you need.
It is not an operating system: it respects the differences between platforms rather than hiding them.
It is not cloud first: the nominal operation is local, remote access remains an extension.
It is not an orchestrator: no central component drives the others.
This vision is developed in What morfSystem is not.
Each project exists for a single reason, expressible in one sentence. A new need yields a new project, never a more complicated one.
A component must be useful even on its own. Cooperation with others is an improvement, never a condition for it to work.
Services are designed to run on their user's network, with no remote infrastructure. External access is a possible extension, never an obligation.
Components collaborate through their public interfaces, never through their internal workings. An implementation can be rewritten; the contract stays stable.
When an open standard answers the need (HTTP, JSON, UDP, text files), it is preferred. Reaching for a specific technology must always be justified.
We solve the problem with the minimum necessary complexity. A proven solution is often better than a newer but more complex one.
The principles are detailed in Architecture principles.
Although the components stay independent, they share a set of conventions.
A clearly identified responsibility, a public API when a service communicates, network discovery through morfBeacon, usable logs, an explicit version number, a free licence: these conventions change little and form the stability of the ecosystem.
The common tools, such as morfTools or morfBeacon, help this coherence without becoming mandatory dependencies.
The shared conventions are described in Governance and Development rules.
morfSystem does not try to follow trends.
It tries to build a coherent, robust and understandable whole.
Languages, libraries and platforms are only means.
A component is judged by its responsibility, never by its technical stack.
That is why a technology is never adopted simply because it is recent.
Before adding a feature, it seeks to preserve simplicity.
It is this philosophy that ties all the projects together.
Far more than their code.
The morfSystem repository describes the common principles of the ecosystem.
Each project then has its own dedicated documentation.
If you want to dig deeper, we recommend the following reading order:
- Getting started
- Philosophy
- Architecture
- Architecture principles
- Development rules
- Governance
- Ecosystem
Want to take part? Read Contributing: how to propose a component, the conventions to follow and the hard rules.