[asadjb]

I disagree.

If I've built a small library that does something useful for my set of needs, it's not crap software. It works perfectly well for my needs.

If someone then goes ahead and uses my library, without understanding what needs it satisfies and what it does not, how is that on me?

I release it to the world with the understanding that someone else might have the same requirements that I had when I built it. Why shouldn't I have released it?

[dunkelheit]

Most of the time yes, but it is not so simple. There is a common resource that can be described as "attention of people who are looking for a library for X" and every time you publish a library for X you use up a bit of this resource. Most of the time this effect is small and more than offset by the value of your code, but it is not zero and overusing this common resource is a dick move.

As an extreme example consider content farms like eHow. After all, they simply publish some low-quality how-to guides, no one is obliged to read them. Why then are they so universally reviled?

> If someone then goes ahead and uses my library, without understanding what needs it satisfies and what it does not, how is that on me?

Being upfront and clear about the needs it satisfies is good documentation practice and plain common courtesy. If you did it and they still misunderstood, then yes, it is on them.

[watwut]

I find this standard ridiculous. We dont apply similar standards to blogs nor videos nor art - them being crappy is not "taking away our attention resource".

Publishing them is not using someone elses attention. And I dont go around hating on eHow. I do expect google to put them down in ranking over time and I do structure my queries so that I dont hit them.

Also, small one time open source project is not tweaking SEO like content farms. That comparison does not work either.

[dunkelheit]

I acknowledge the difference, but it is quantitative, not qualitative.

> We dont apply similar standards to blogs nor videos nor art - them being crappy is not "taking away our attention resource".

That's because the attention cost was driven way down by awesome information retrieval systems that we have (google, etc.). But the cost is still there and it is a good idea to compare it against benefits. Again, this doesn't mean that you should not publish anything.

> Publishing them is not using someone elses attention.

If you publish anything, you expect it to be found by someone (otherwise, why publish at all?). Voila, you've used their attention.

> And I dont go around hating on eHow. I do expect google to put them down in ranking over time and I do structure my queries so that I dont hit them.

This just corroborates my point that the cost is real. In this case the cost is paid by google (they have to expend resources to fight SEO spam) and you (you have to reformulate your queries).

> Also, small one time open source project is not tweaking SEO like content farms. That comparison does not work either.

I'm afraid without concrete examples we are talking past each other. Of course a small-time project that is clearly marked as such is totally OK, but the original post by saurik mentioned squatting common names and overpromising on features, which is definitely into the SEO territory.

[saurik]

Ah yes, I certainly have never seen anyone complain about the signal-to-noise level of low-quality blog posts and videos about topics where people are trying to learn about something like COVID-19... oh, wait ;P.

The reality is that when you publish your package someone else who is trying to get something done is going to use their package manager's search feature to look for like "jsonrpc" and find your half-assed for-personal-use-only jsonrpc library as one of the results; great... now, they have to look at your readme file, open issues, and maybe do some kind of code review to verify whether you are taking this seriously enough for them to rely on your package or not. Of course, a lot of times they aren't even skilled enough to do that analysis correctly as they are just getting into software development and that is hard to do. Worst case you end up higher in the search results than an actually-useful package because you sniped a name like "jsonrpc" or "jsonrpc-client".

This is then the point where (and I am not saying you yourself do this, but this is the developer I am most upset with, and this is as someone who long ago mostly gave up using anyone's packages and now mostly deals with this by being the "wet blanket" constantly trying to convince other people about how low quality some random package they shouldn't be using really is) if your readme file talks about how awesome your package is and has a bunch of past tense descriptions of things you didn't get around to finishing and never will--things you might not even accept patches for or feedback on because this was a project you did over the weekend and are now done with and you didn't really sign up to be an open source maintainer--you aren't just using other's attention, you are outright being a jerk and need to really ask yourself what you are doing by publishing your package in the first place :(.

[onemoresoop]

If one explains well what it is then they can’t be expected to support the parts of what that project is not.

I second the comment above about having a honest description to waste other people’s time.