The reason you published it shows in the code

People open source their code for four different reasons and the reason they did it’s visible in what they put out.

The first group is using the repository as a resume. They know someone may read it in an interview context so they put a great deal of effort into making it work well, look tidy and read cleanly and the result is usually the best code any of these groups produce. It’s also code shaped by an audience that may never turn up, which is a strange constraint to build under and produces its own odd effects.

The second group believes in the thing. They want what they built to be shared so other people can use it more freely and add to it and improve it and their code generally looks good and reads well without quite reaching the polish of the first group. That gap isn’t carelessness. It’s a difference in what matters, because for this group the results the software produces are more important than the impression the source makes and time spent on presentation is time not spent on the thing working.

Wanting to be known is the third. Publishing is a way to build a reputation so things get a bit of polish before they go up and quality tends to come second to quantity, since the reputation is built out of the count rather than any particular repository. This one is easy to be sniffy about and probably shouldn’t be, because a lot of really useful software exists because someone wanted their name on something.

Group four simply hasn’t made anything private. They write code for themselves, they push it somewhere public because that’s the default and there was no reason to pay for the alternative and they don’t much care whether anyone ever looks at it. The code is usually pretty hacky and it doesn’t matter to anybody, including the author, because nobody is reading it. I’m in the fourth group and I’ve been for years.

That’s why the anxiety about publishing something not good enough is worth examining before you act on it. The question isn’t whether your code meets some absolute standard, because there’s no such standard and the average public repository is a long way from one anyway. The question is which group you’re actually in, because that determines what the code is for and therefore what good enough even means.

If you’re in the second group and you’re hesitating because the source is untidy, you’re applying the first group’s standard to a piece of work with a different purpose. Tidy it up as much as you fairly can and then publish it and don’t lose any sleep over the parts that are ugly. The people who benefit from what it does aren’t the people who were going to audit how you did it and waiting until it reads beautifully mostly means it never goes out at all.

The one thing worth being honest about is which group you’re in, because it’s very easy to tell yourself you’re in the second while behaving like the third and the difference shows up in whether you keep working on something after the initial attention has moved on.

There’s a fifth case that doesn’t really count as a reason, which is code published because a client paid for it and the contract said so. That one produces the strangest repositories of all. The code is usually fine because someone was paid to make it fine, and there’s nobody left who cares about it, so it sits there working perfectly and slowly going out of date with no issues, no releases and no answer to any question you might have.

When you’re weighing up whether to use something, working out which group it came from tells you more than the star count does.