[PaulShin]

You've absolutely nailed the history and ethos of Git, and it's a crucial distinction. Thank you for the clarification. You're right, it wasn't a "product" in the modern sense.

My analogy wasn't intended to be about the UI or its 'one thing well' philosophy, but about the category of friction it eliminated.

Before Git, the coordination overhead for code was immense think manual patches and diffs. Git didn't write the code for anyone, but it automated away that specific, painful "collaboration tax," freeing developers to focus on the actual programming.

I see a parallel today, but the "collaboration tax" has moved. It's now the manual, repetitive work of translating team conversations into structured tasks. We believe that specific friction can also be automated away, freeing teams to focus on the actual execution.

So, you've helped me refine the analogy: It's not about building a product like Git, but about tackling a problem in the same way Git did by automating a specific, painful type of coordination overhead.

[brudgers]

Before Git

SCM was a solved technical problem.

The Linux kernel team used Bitkeeper for Source Code Management.

The problem was Bitkeeper’s license.

Github built a business on top of git by making the existing tool easier to use. They did not build an SCM.

[PaulShin]

That's an even more precise and insightful framing. You're absolutely right—the catalyst was licensing, and the technical problem of SCM was, in a sense, already "solved." Thank you for sharpening the point further.

You've actually given me the perfect "Part 2" of the analogy "the relationship between Git and GitHub."

Yeah, Git is the powerful, low-level engine. Technically brilliant, but with a notoriously steep learning curve. The real explosion in adoption came when GitHub wrapped it in a user-friendly product with a clear workflow (pull requests, issues, etc.). GitHub didn't reinvent SCM; it reinvented the collaboration workflow on top of it.

That's exactly how we see the problem we're tackling. The "protocols" of modern work already exist: real time chat, task lists, documents. But they exist as separate, low-level primitives, like Git commands. The "collaboration tax" comes from users having to manually act as the interface between them.

Our goal is to be the "GitHub for general collaboration." To take those existing primitives and build a seamless, opinionated workflow on top where the connections are automated. The user shouldn't have to think about the "protocol"; they should just be able to work.

So, your point is well taken and helps clarify our position. We're not trying to build the "Git" (the core primitive). We're trying to build the "GitHub" (the intuitive workflow layer that makes the primitives powerful for everyone).

And that philosophy is baked right into our name. The reason we're called Markhub is because we're building a central "Hub" where every "Mark" a team makes a message, a decision, a task, a document can live together in a single, seamless flow.