[sherdil2022]

My contrarian view is that if someone wants to get stuff done, they will get it done or find a way to get it done. Or else there will always be one excuse or another. Of course, there might be some legitimate blockers or onorous processes, but you don’t need a reason to do stuff and one can come up with thousands of reasons to not do.

[PaulShin]

Fair point no tool can manufacture intrinsic motivation. At the same time, even highly motivated people hit friction: digging through chat history, duplicating context, or chasing down “who owns this.”

The goal of what we’re building isn’t to make someone work; it’s to strip away the overhead that slows down people who already want to.

Think of it like version control: Git doesn’t write code for you, but it removes enough coordination pain that good engineers ship more often. We’re aiming for the same effect between conversation and execution—same motivation, less drag.

From our side, the north-star is a radically simple answer: let a single chat thread end all that visible complexity. One place, one flow, nothing to copy or sync. That’s the product we’re building toward.

Curious have you seen lightweight workflows that actually cut this friction without adding new layers?

[brudgers]

Git was dog fooded by a community of programmers.

Has a user interface only Linux kernel developers could tolerate.

And was written by one programmer in ten days.

It was not a product and in accord with the Unix philosophy, only does one thing.

[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.