> ## Content Index
> Fetch the complete content index at: https://zahradnik.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# Managing projects that are partially closed-source
- URL: https://zahradnik.io/managing-projects-that-are-partially-closed-source/
- Published: 2026-04-14T08:40:47.000Z
- Updated: 2026-04-14T08:40:47.000Z
- Author: Vladimír Záhradník
- Tags: Systems, Friction

Most tools assume one thing:

> your project is either open-source or closed.

In reality, many projects sit somewhere in between.

---

Last year I joined a SaaS project as a consultant.  
When I arrived, everything was closed — including internal tooling and documentation.

Six months later:

- documentation is open-source
- one integration is open-source (MIT)

But the system is still **partially closed**.

---

And that creates a specific kind of friction.

During routine reviews, I would hear things like:

- “This invite link is outdated, we have a verified integration now”
- “Don’t document this feature, it will be removed soon”

The insight exists — but only in the founder’s head.

---

This doesn’t scale.

If you want to grow a team, knowledge cannot depend on one person’s memory.

---

## The problem

Open-source parts live on GitHub.  
Closed-source parts live somewhere else.  
Decisions live in conversations.

There is no single place where the system is visible as a whole.

---

## The solution: a meta repository

Instead of trying to force everything into one system, I introduced a simple layer:

> a meta repository

An empty Git repository with a README that explains its purpose.

That’s it.

![README defining scope and boundaries of meta repository](https://storage.ghost.io/c/98/55/9855d37b-ac20-4dfa-abf2-b089f6222e9f/content/images/2026/04/image.png)

What belongs / what doesn’t

---

Now you can:

- create issues for the product as a whole
- track decisions across open and closed parts
- discuss changes in one visible place

As if the entire system was open — even when it’s not.

---

## Taking it further

If you want structure:

- create a GitHub Project (Kanban is enough)
- define a small set of labels (area, priority, status)

This turns the meta repository into a coordination layer.

![Kanban board showing issue progression stages](https://storage.ghost.io/c/98/55/9855d37b-ac20-4dfa-abf2-b089f6222e9f/content/images/2026/04/image-1.png)

From issues to workflow

---

## Why this works

You don’t fight the system.  
You don’t force the founder to change tools.

You simply create a **visible layer above everything**.

---

Setting this up takes 30–60 minutes.

It pays off immediately.