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.