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.