Comment by saurik

I agree: it is OK for your open source library to be a bit shitty. However, it also can simultaneously be not OK for you to publish it in a package directory with a generic name and a description talking about how awesome it is as a trap for other people to run into, and that is really the core problem: it isn't that you didn't spend an unreasonable amount of time and money to make a good product that no one paid for (though I do know--all too well, as the sole maintainer of some key projects for a sometimes ungrateful ecosystem--that there are many people who really are just looking to be assholes), it is more often that you overhyped a side project and then put it somewhere obvious for other people to find it, only for them to discover that it was "a bit shitty" long after they deployed it; and sure: it is totally their fault for deploying something without carefully reading your code to figure out that it was a bit shitty beforehand... but should they really have to do that? When you release code that you don't intend to back up with a ton of time and resources, please do the rest of us a favor and use a name that no one is going to mistake for a standard package, put a note on it that says "this is a side project" so expectations are clear, don't write a readme file in the past tense about features you hope to one day implement, or, if you just can't bring yourself to be responsible like this, maybe just reconsider whether you need to publish it at all, as it actually doesn't necessarily make the world a better place just because it is open source. Seriously: if you bring something that you know tastes bad or will make someone sick to the potluck and put a little sign on it saying "gourmet enchiladas: much better than what you get at the store" and put it in the center of the table, it is still a problem even though "it is ok for you to not really know how to cook or not have that much time and participate in the potluck anyway".