Questions missing from this list are:

"Can I spend some amount of money and be done?"

"Is this worth spending some amount of money to be done?"

I have had innumerable projects where they just languished and languished and languished ... until I got annoyed enough to spend some money and then they were done and gone.

Sure, some projects are a "hobby". My hobbies are continuous and I like doing them so spending money to finish them is not relevant.

However, quite often a task languishing is either because I don't really like the task or don't feel like putting in the effort to learn the required knowledge. For those tasks, spending money often works.

(For example, my latest task along these lines was "sharpen my kitchen knives". After farting with far too many whetstones, I finally spent the money to buy a fixed-angle sharpening system. I took it out of the box, set it up, and in two evenings my dozen kitchen knives were sharp and pleasant to use again. I then put the system back in the box and put it in my closet for the next time I need it. I spent way less on that fixed-angle system than I have on the whetstones I tried up to this point.)

I've accepted that all the progress for me happens in tight bursts. I simply cannot do 'thought work' when I'm disinterested. I sometimes envy people who are interested in one particular project for years or decades at a time and make plodding, continual progress. However that's not me. I make inspired, unbelievable progress, and then nothing. I try to constrain the scope so that it at least remains useful, in between the bursts.

I've made the decision to "brownfield" many projects. My GH[0] is full of archived, and even private, repos that I no longer maintain. I have retired most of the apps that I've written. I only have a few left on the App Store[1].

I do make sure to explicitly "freeze" a project that I'm no longer maintaining, and indicate such, in the README. I hate encountering abandonware that is only obvious, because of the last modified date.

But the projects that I do want to finish, I make sure to do a "full-fat" job. If I consider it "done," then it gets the Full Monty. I also continue to maintain. If I can't do that, it gets archived; even if I had completed and shipped it.

Those are valid questions, but I don't usually get that exacting. The projects that I walk away from, are usually because they were just for learning, I got into a "death spiral," or that were eclipsed by something else.

[0] https://github.com/ChrisMarshallNY#browse-away

[1] https://littlegreenviper.com/AppDocs/

Even when I know that I should not finish something, there is still a surprisingly robust mental barrier that holds me back from it. The solution that works for me is the making a 'Low priority' folder to put those projects I know I don't need to finish. Moving them out of my active workspace feels great, and the 'low priority' means its non-committal to completely abandoning them (although in practice 99.9% of the time, that exactly what the result is).

This is a mental trick I play on myself that I know that I am doing, but somehow its works anyway.

Questions to ask when you think you need to finish something? Sorry for the nitpick, typically my brain completes missing words easily. Must be the lack of coffee here.

this is the same drack which appears endlessly on Linkedin and bluesky and lil blogs. Guess whatelse is pushed? the same drack in a Newsletter! Not interested and Hacker news is for so much better content than this horseshit.

Thank you for your considered words. I need something like this. It helps.

I have a thing. I solved a riddle after much labor. Having solved it the fire is gone AND much new possibilities have opened. So that's the dilemma.

I'd love to read something longer about this.

Didn't feel the need to check the grammar of the title as the essay no longer aligned with goals and interests.

I've been consulting since 1984, and before there was a notion of "open source" I (and others) had a notion of "tools of the trade" that we wrote into contracts. These had to be finished enough in a conceptual and artifactual sense sufficiently so as to be distinguishable from what was delivered to the customer as the customer's property. How public these tools would be was negotiable. There wasn't necessarily support, but there was often an expectation that bug fixes or functional enhancements would be shared with prior recipients / licensees.

So that's kind of my grounded understanding of "finished": that something is "finished" given the context it operates in. Meets some contractual specifications.

I give away the core components of an (mildly SIEM-like) observability platform on GitHub. I publish demo clients, but I don't publish the actual clients which I utilize in production. I will give them to you if you make friends, demonstrate that you can steer the core components, and demonstrate that you're capable of providing useful, cogent feedback.

This is a support issue. I don't have the time, patience, or interest to provide support theater. I'm not that interested in the clients, per se; I'm more interested in what they accomplish for me. Let me put it plainly: I'm interested in what they do for you if you pay me money to be interested, or I find your particular application of personal interest. I don't want to hear that the clients are crap because they don't solve your personal problem pretzel. I don't want to hear that the client doesn't work when the server components aren't set up properly.

I'm pretty comfortable with stuff being finished for a given context. That functionality in that context is a kind of oasis or petri dish, and if stuff manages to transplant to a different context or different inhabitants come to the oasis then I'm generally interested in looking at that and reexamining "finished"; and that's why I put it out there, in public.