When people say they build a privacy-first product, I ask one simple question:
How much of the implementation story is publicly verifiable?
For MindMapVault, I decided to put a significant part of the project in public repositories because I do not want trust to depend only on polished copy.
Short background
Since my university studies, free and open-source software shaped how I learn and build.
I learned from maintainers I never met. I used products I could inspect, fork, and improve. That openness gave me a practical education I could never get from closed products.
Open sourcing this project is also a thank-you to that ecosystem.
Why this is important for private-thinking software
Mind maps are not harmless doodles.
They often contain strategy, unfinished research, priorities, and personal structure. If a product claims privacy, users should be able to evaluate whether boundaries are real.
Open repositories allow people to inspect:
- architecture decisions
- release history
- deployment options
- public issue and maintenance patterns
That does not guarantee perfection. But it does remove the black box.
For developers and operators, this also answers a practical question: can you run a self-hosted mind mapping app for free in a home lab and still evaluate the trust boundaries? In this case, yes.
Public links
Repositories
- MindMapVault FOSS: https://github.com/mindmapvault/mindmapvault-foss
- MindMapVault Server: https://github.com/mindmapvault/mindmapvault-server
Container images
- GitHub Container Registry (MindMapVault Server): https://github.com/mindmapvault/mindmapvault-server/pkgs/container/mindmapvault-server
- Docker Hub image: https://hub.docker.com/r/kornelko2/mindmapvault-server
Why home lab users care about this
When you run a free self-hosted mind mapping app in a home lab, you are not only looking for features.
You are also checking:
- can I inspect the code path I am deploying?
- can I follow release history and rollout changes safely?
- can I keep infrastructure ownership without hidden lock-in?
Open-source repositories and public image links make those checks possible.
Practical outcomes of building in public
- Better engineering hygiene
Public changes force clearer commits, documentation, and compatibility handling.
- Better technical conversations
Feedback can be concrete because people can reference real files and real history.
- Better trust posture
Users and teams can evaluate what is implemented instead of trusting only messaging.
- Better self-hosted operations
Home lab and self-hosted users can review deployment docs, compare tags, and plan upgrades with fewer surprises.
What open source is not
Open source is not a license to expose secrets.
We keep a hard boundary between transparent implementation and private operational data. No private keys, tokens, or user data belong in public code.
Closing
I want this project to be understandable to people who care enough to inspect it.
Not because it is perfect, but because trust grows faster when code, decisions, and trade-offs are visible.
If that resonates, check the repositories, open issues, and challenge assumptions.
If your specific goal is a free self-hosted mind mapping app for your home lab, start with the public repos and container image links above, then verify the architecture against your own privacy requirements.
That is the kind of software culture I learned from, and the one I want to contribute back to.
Top comments (0)