Issues

This week was a short one.
Partly due to a bout of food poisoning and partly due to my parents visiting.

I didn’t achieve as much as I would’ve liked. I suppose I could be harder on myself, as I was in the past, but I don’t find the need to do it now.

Part of me knows that self-flagellation isn’t actually so productive a habit and part of me also just fails to find any fault with the time I spent otherwise. I do regret eating that skeptical bit of seafood, but I don’t regret enjoying time with family.

There was a talk last summer with Paul Graham and the bit of advice that stuck the most was to never forget about family. As founders, we tend to act quite self-important. There’s always some event, some crisis, some thing that is going on and is the target of our obsessions. So we often overlook the people that are always present in our lives: our family and our friends.

And while I don't think of myself as a particularly "good son," I do strive to be a decent one at the least, and hope to be present with those around me whenever I can. Anywho, onto issues.

Issues were the first reason we started working on gitdot.

I spent a few days in August profiling a bunch of open-source projects and being rather appalled at the state of their issues. They were these long slogs of poorly written, low-effort customer support requests, and seeing the maintainer go from ticket to ticket, attempting to triage and root-cause them left me with the keen impression that there was a problem here.

The solution that I thought of was some sort of SuperHuman-esque tool that would make it really really easy to go through and reply to GitHub issues. The idea was that all issues should be in either of two states: not replied or replied to, and that we would be aggressive in encouraging an “issue zero” philosophy.

There was also the admittedly more-optimistic idea of an AI bot that used a few coding agents to respond to issues directly, but a few hours prototyping that led us to believe that it was both a nascent idea and one that was not particularly defensible either.

Since neither seemed like it would make for a tenable business, we decided to move on. But I do remember thinking that of all things, issues seemed like a clear problem, and a real grimy one at that.

So it’s quite exciting that we get to work on issues now.
Genuinely, the prospect gives me some joy.

I have quite the history with to-do apps (used to organize my entire life in emacs org-mode) and am both the avid user, and critic, of quite a few project management tools (a fan of Linear, both as product and as company). But as I spent a few days this week thinking, designing, and ruminating on issues, I chose not to implement it instead.

That sentence surprises me as well, but the rationale for it is as follows.

I think context is important.
And no, I’m not referring to agentic context and all the sorts of hacks that are going around masquerading as “AI research,” but context as defined by the circumstances that form the environment we live in. Products aren’t created in a vacuum, they exist in a context — in a market with plenty of alternatives and complementary tools.

So while it is possible for us to create a project management tool (and I would no doubt be very excited to), I started to rethink the utility of that in context of alternatives.

I use Things, a great Mac todo app, to organize my work and my life.
I don’t have any problem with it, and while I could theoretically migrate my todos to some system of gitdot issues, it’s not clear that it would be incremental.

I’m sure I may “think so,” because it would work in practice and solve my own problem too, but that value is only driven in absence of alternatives. In the larger context of the plethora of project management tools out there, the only reason I would use gitdot issues would be my own vanity.

So what we chose to focus on is what sole function could we uniquely provide instead?
And that’s where things got interesting.

Open-source is very different than closed-source development.
Despite there being quite a lot of overlap in the abstract (you can argue that everyone needs source control and everyone needs customer support), the marked difference between the two is the number of parties involved.

Customer support is typically some variable cost function that scales to the number of in-bound tickets. If you have a lot of customers, you will have more tickets, and that is something you must attempt to optimize for by minimizing cost and maximizing customer satisfaction.

The closest corollary for customer support in open-source development is issues.
But in contrast to private companies, every single issue created in a repository is public.

It can be read by anybody else on the internet, meaning that each issue created has the opportunity to not only benefit the requester, but other people as well.

That doesn’t tend to be the case for GitHub issues as-is, where the form of the product makes it more akin to a typical customer support ticket, but there are successful examples elsewhere that prove the more commons-based model.

StackOverflow is one.

The core insight of StackOverflow is that conversations don’t scale.
The more back-and-forths you have, the more costly communication is for all parties involved, and the less likely that a timely resolution is reached. So as much as you can, motivate people to provide all information upfront. This means that not only can responders resolve the question, but also that other people reading the post can benefit from the same.

If people are aware that their questions have a public audience, they will approach it less as if they were messaging a friend, but as if they were standing up in lecture and making a public statement instead.

This pressure on asking "good questions" is perhaps the most polarizing aspect of StackOverflow as well.

The platform has traditionally struggled with the “homework question” — a long queue of new developers that don't do due diligence and ask lazy questions. In response, the community and the platform actively built mechanisms to discourage bad behavior, things like low-quality flags and aggressive moderation queues. That in turn, proliferated the sort of elitist culture that people associate StackOverflow with.

My first impulse was to do much of the same.

Build this for the maintainer, and not for the “noob” who is polluting my repository with dumb questions and false bug reports. But I realized that the answer isn’t so clear cut.

People asking questions is actually a good thing.

It’s one of the few ways that a maintainer can understand his customers.
And even though we may think of certain questions as “dumb,” it is likely that if somebody asks a question, another person will have the same.

Furthermore, responding to questions is also a very natural way to go about writing documentation. Rather than treat documentation as an exercise in the encyclopedic, doing it as a Q&A is both easier and more uniquely valuable. It is interesting to see a maintainer respond with his views on a particular feature or a design decision made. It’s simply rare to see artifacts and thinking from really good engineers.

And the context has changed.
The lazy option is no longer StackOverflow, it’s AI.

It is not possible to build a cheaper or a more convenient answer to simple technical questions than AI.

And while that may cause fright to folks who had previously filled that niche (i.e., StackOverflow), we see it differently.

For one, it means that instead of discouraging users to ask questions, we can actually do the opposite and make it easier. Because no matter how easy we make it, waiting on a reply from a maintainer is strictly more expensive than to rumble to Gemini. So we posit — wouldn’t the quality of questions go up even as we make it easier to ask questions?

Secondly, there are certain questions that only people can answer.
I've had to do quite a lot of spelunking recently in understanding Next.js and all the weird finicky details with React Server Components, Server-Side Rendering, and Cache Components.

Claude is admittedly poor in its knowledge of new frameworks. And no discredit to it, how would it know about something that was released a few months ago, poorly documented, if at all, and only discoverable by reading the source code.

And while it is possible for agents to figure out a way to get something working given enough source code and tokens, that's a different thing than figuring out the best way to do something.

Best practices are ingrained in many codebases for historical frameworks, but for the bleeding-edge, it's a different story. We, as developers, are in the process of defining what that is — and believe that debate of strong opinions is how you converge upon an answer.

For all its faults, the competitive peer-review culture that StackOverflow encouraged resulted in an incredible amount of interesting content. I do credit the site with helping me become a better engineer, and it is a bit sad to think that a space for that is dissipating.

So in short, we’ll be cooking something up soon.

The week has made it clear how deep and how different open-source really is.
It is truly and sheerly fascinating — as an economic model, many laureates have used it as a case study for something that really shouldn’t exist, but still does nonetheless.

And in each feature we build, each interaction we design, we’re reminded of that fact.

Building things for the public is very different than building things for the private, and I think we’re only beginning to scratch the surface in understanding what that means.

Thank you
—baepaul.