10 ms·

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 wi

by saurik 7y ago

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".

nexuist 7y ago
> 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: As far as I can tell this is a node-specific problem. I would argue it's a byproduct of resume-driven-development, not of open source culture. I think the onus is on npm to guard against obvious click grabbing projects (like is-odd, is-even, leftpad...), but it's also on the JS standards committee to develop a standard library that doesn't need 1 or 2 line dependencies to function the way a reasonable human would expect it to function. > 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? Yes, you should at least read through the README and take a look at the issues before using any project. Code with 0 issues filed, no forks, and no stars...should not be used in production without proof reading. You can get a benefit of the doubt if it's clearly a popular project (i.e. apple/swift, google/flutter), because at least then you know multiple people before you have tried it out and been satisfied enough to want to help out. > 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 The problem is that this is subjective. What does "tastes bad" mean? Are you expected to know what will make someone throw up? Sure, you'd be a dick for serving raw chicken - but the raw chicken projects generally don't have READMEs in the first place, because they were never intended for usage by others. It's your fault if you incorporate raw chicken into your meal and get sick from it. The problem is that some people view a package manager as a farmer's market while others see it as a restaurant. Should you serve gourmet meals, or are berries OK too? If you sell raw chicken at a farmer's market, it should be obvious to the consumer that they have to cook the chicken first before eating it. The problem is when a customer goes to a farmer's market expecting it to be a restaurant and gets sick from something they didn't understand.
- TAForObvReasons 7y ago
  While `left-pad` certainly wasn't the most optimized implementation, it wasn't a "click-grabbing" project of the sort saurik was positing. It solved the problem the name suggested it would solve. The fallout around it really didn't have anything to do with "resume-driven development" EDIT: Not sure why this was downvoted, maybe people forgot that padStart and friends appeared in ES2015, long after left-pad was created
  - vxNsr 7y ago
    off-topic: I still don't understand the use case that left-pad solved. I'm not into js at all but why do you need a dependency to add space to text? I'm asking honestly, I just don't get what the use for this was.
    - d3nj4l 7y ago
      JS didn't have a pad method in its standard library, so you needed left pad to do that. Now you have padStart, so it's not really necessary.
    - scambier 7y ago
      Literally what it says: https://github.com/left-pad/left-pad/blob/master/index.js https://github.com/left-pad/left-pad/blob/master/index.js Now if you ask "but why?", ultra-small packages like this are popular in JS because of the lack of a standard lib. Lots of devs prefer to install a dependency for each one-liner utility rather than write them themselves. The only added value of those packages is that they're usually unit-tested against weird edge-cases that you might miss if you wrote them yourself. Edit: related discussion at https://news.ycombinator.com/item?id=20223190 https://news.ycombinator.com/item?id=20223190
      - TAForObvReasons 7y ago
        the small libraries are best compared to stackoverflow code snippets. Instead of reading and copying a solution that may be out of date, you can use a (theoretically) tested solution that receives bug fixes. In many ways it is superior to the copy and paste of lore
DangitBobby 7y ago
I need to publish it publicly to install it via pip, npm, cargo, etc. for public use.
- mroche 7y ago
  Pip does not need a package to be public in order to install it at all, I’ve installed plenty of packages from tarballs and directories just fine. From the docs[0] Install packages from: - PyPI (and other indexes) using requirement specifiers. - VCS project urls. - Local project directories. - Local or remote source archives. Although I’m not quite sure how you’re using “for public use” in that sentence. [0] https://pip.pypa.io/en/stable/reference/pip_install/#id19 https://pip.pypa.io/en/stable/reference/pip_install/#id19
  - DangitBobby 7y ago
    I meant to say private use, not public use. But if I want to install from pip over the internet, which is my most common use case it needs to be publicly accessible, right? Which for me means GitHub, bitbucket, pypi, or some other bespoke solution just to avoid "publishing" something for my own private use. Or do I misunderstand?
    - lionyo 7y ago
      You can publish to a local instance of PyPi https://www.linode.com/docs/applications/project-management/how-to-create-a-private-python-package-repository/ https://www.linode.com/docs/applications/project-management/...
      - DangitBobby 7y ago
        I could do lots of things that would be unnecessarily burdensome for the dubious benefit of having my package unpublished. If it's acceptable to install it on a local network I can just do it directly from a normal filesystem.
    - JimDabell 7y ago
wolco 7y ago
"sure: it is totally their fault for deploying something without carefully reading your code to figure out that it was a bit shitty beforehand" Yes you must read and understand everything or have trust in the publisher. Relying on the package name is going to get you in trouble. Sounds like a great exploit opportunity.
- sabas123 7y ago
  What if I have no reasonable way of fully understanding the code nor being able to judge the author on their trustworthiness (even disregarding that this isn't constant). As a community we need to accept that the above mentioned DOES happen. Pretending otherwise only hurts us all.
  - TeMPOraL 7y ago
    > As a community we need to accept that the above mentioned DOES happen. Pretending otherwise only hurts us all. In fact, it happens very often when people are learning and exploring. So imagine I publish my shitty library "with a generic name and a description talking about how awesome it is". Imagine you're trying to learn $language. You buy into my deception and try to use my library. You get burned, and might be left with an impression that $language or its ecosystem is shitty, and never return, despite the fact that $language would suit the kinds of problems you're solving really well. If it happens enough times with enough libraries, $language may get a bad reputation. Preventing this becomes a matter of protecting the common good.
    - bigiain 7y ago
      Hands up everybody who remembers "Matt's Script Archive"? (Hmmm, just the greybeards. I could have guessed that I suppose...)
  - watwut 7y ago
    One way to judge that is by whether the project was consistently maintained, what kind of issues are reported and if the important ones are fixed. So if the project seems to be ignored (no issues), if it has tons of them and no response, you won't use it or use it only with caution. Newcomer to langue or ecosystem should use popular frameworks and libraries, so that there is help available.
enraged_camel 7y ago
The way I look at it is that releasing an open-source library is like bringing a child into this world: its utmost well-being is your responsibility. If you don't have the bandwidth for that, don't publish it. And, if your circumstances change later, find another maintainer -- after all, you wouldn't just abandon your child on the street, would you?
- ProZsolt 6y ago
  It's not a child. It's a hammer. Somebody put it in the community shed so others can use it. If it breaks or somebody needs a nailgun, that's not their problem. I'm glad if somebody lent me their hammer so I don't have to buy one, even if it's not the best.
matheusmoreira 7y ago
> it also can simultaneously be not OK for you to publish it in a package directory with a generic name and a description Package repositories can be open to all developers or curated by software distribution maintainers. Being able to publish an open source project without dealing with Linux distribution maintainers is a major selling point of programming language package managers. Why even let people publish packages if they're not meant to? > 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? Absolutely. Using someone else's code means implicitly trusting them. Everyone should at least check out the package's source code for quality, sanity and signs of maintenance.
- Vinnl 7y ago
  > Why even let people publish packages if they're not meant to? I don't think GP even so much as insinuated in their post that people aren't meant to publish packages in general.
  - matheusmoreira 6y ago
    The argument was: only packages which are good enough for production use ought to be published on official package repositories. This allows people to assume that all packages on the repository are stable, well maintained, good quality software without manually verifying each dependency. So why even let random people sign up a developer account and publish packages? Maybe they need a separate curated "serious packages only" repository.
- ex_amazon_sde 7y ago
  > Being able to publish an open source project without dealing with Linux distribution maintainers is a major selling point of programming language package managers. This is how disasters like leftpad happen. The bar for publishing software is extremely low and we pay the price every day in terms of security, bloat and complexity.
  - watwut 7y ago
fendy3002 7y ago
I agree with readme needs to specifically mention unimplemented features. But the responsibility for using an unpopular library lies fully on the user, not author. Of course if the library is popular, author needs to maintain it, or delegate auhority to other maintainers. As user, it's clear that you need a feature which you found on an unpopular library. Now rather than be skeptical and research the library, or wrap it under yours so you can replace it later, or develop your own, you decide to blindly use it and blame the author.
bigiain 7y ago
There's a license for that: http://matt.might.net/articles/crapl/ http://matt.might.net/articles/crapl/ I know free software debaters and open source license philosophers love to hate on this one, but the fundamental core concept of "more importantly, it should absolve authors of shame, embarrassment and ridicule for ugly code" in the context of them choosing to release code or not is a great idea I reckon. (But I agree wholeheartedly with the thrust of your argument, and am of the opinion that if you spent more time on the logo design or website marketing copy for your library than you did writing the code, then "You're doin' it wrong...")
- anticensor 7y ago
  > 1. By reading this sentence, You have agreed to the terms and conditions of this License. The craziest click-to-accept clause I have ever read.
  - bigiain 7y ago
    Alternatively, most obvious joke license ever... (or in retrospect, perhaps "equivalently" rather than "alternatively")
  - jessaustin 7y ago
    Thanks a lot guy! By pasting that awful sentence into this thread, you've forced all of us reading here to agree to the license!
dunkelheit 7y ago
Agreed. People who demand free labor from open-source maintainers get a lot of deserved flak lately, but it is not that project authors are always blameless. Everyone who publishes some code for others to use faces a dilemma: they want their project to be popular (because being associated with a popular project is prestigious), but popularity means that the project demands additional effort to polish it, deal with bug reports and pull requests etc. So there is a temptation to convey the appearance of maturity without putting in the required effort. So yeah, it is totally OK for your open source library to be shitty, but please state this clearly in README to save everyone's time.
- AnIdiotOnTheNet 7y ago
  I agree. If you are actively marketing a project, you are declaring yourself open to criticism. You don't get to play the "what do you want for free?" card and say "my thing is totally awesome and you should use it!" at the same time.
  - cycloptic 7y ago
    Yes you do. I do that all the time. It just depends on who you're talking to. You can usually tell within a very short period of time who is going to get invested and add value, versus who is going to fall behind and demand a disproportionate amount of attention.
asadjb 7y ago
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 7y ago
  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 7y ago
    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 6y ago
      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.
fudged71 7y ago
Do package directories have moderators? The naming problem has always interested me
Matthias247 6y ago
> 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: I'm observing this regularly. Currently a bit more in the Rust community since I'm more active there, but I think it's a thing that happens everywhere. I think in most situations it happens is is incidentally: The people who wrote those packages do not actually have the experience to observe design and quality issues in their package. They might still be in university, or have a minimal amount of industry experience, and found working on an open source project to be a nice way to be creative. And in one metric that they found for themselves, the might even beat very established projects - let it be performance or finding the new "ultimate abstraction". Therefore they are going forward to market the project as the awesome new thing - without knowing about other important metrics that their project does not meet. I'm not sure how this can be improved. I think it would require experienced reviewers and curators that are willing to look into other peoples open source projects and help them. As well as authors of those projects to be willing to be mentored. Both is not easy. As an experienced engineer you have enough to to that you don't want to look into YetAnotherProject. As someone who wants to hack on a side project as much as possible you probably don't want to waste your time with talking to someone else.
m463 6y ago
caveat usor
mozilianulb 6y ago
Nice

by saurik 7y ago

nexuist 7y ago

> 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: As far as I can tell this is a node-specific problem. I would argue it's a byproduct of resume-driven-development, not of open source culture. I think the onus is on npm to guard against obvious click grabbing projects (like is-odd, is-even, leftpad...), but it's also on the JS standards committee to develop a standard library that doesn't need 1 or 2 line dependencies to function the way a reasonable human would expect it to function. > 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? Yes, you should at least read through the README and take a look at the issues before using any project. Code with 0 issues filed, no forks, and no stars...should not be used in production without proof reading. You can get a benefit of the doubt if it's clearly a popular project (i.e. apple/swift, google/flutter), because at least then you know multiple people before you have tried it out and been satisfied enough to want to help out. > 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 The problem is that this is subjective. What does "tastes bad" mean? Are you expected to know what will make someone throw up? Sure, you'd be a dick for serving raw chicken - but the raw chicken projects generally don't have READMEs in the first place, because they were never intended for usage by others. It's your fault if you incorporate raw chicken into your meal and get sick from it. The problem is that some people view a package manager as a farmer's market while others see it as a restaurant. Should you serve gourmet meals, or are berries OK too? If you sell raw chicken at a farmer's market, it should be obvious to the consumer that they have to cook the chicken first before eating it. The problem is when a customer goes to a farmer's market expecting it to be a restaurant and gets sick from something they didn't understand.

TAForObvReasons 7y ago
While `left-pad` certainly wasn't the most optimized implementation, it wasn't a "click-grabbing" project of the sort saurik was positing. It solved the problem the name suggested it would solve. The fallout around it really didn't have anything to do with "resume-driven development" EDIT: Not sure why this was downvoted, maybe people forgot that padStart and friends appeared in ES2015, long after left-pad was created
- vxNsr 7y ago
  off-topic: I still don't understand the use case that left-pad solved. I'm not into js at all but why do you need a dependency to add space to text? I'm asking honestly, I just don't get what the use for this was.
  - d3nj4l 7y ago
    JS didn't have a pad method in its standard library, so you needed left pad to do that. Now you have padStart, so it's not really necessary.
  - scambier 7y ago
    Literally what it says: https://github.com/left-pad/left-pad/blob/master/index.js https://github.com/left-pad/left-pad/blob/master/index.js Now if you ask "but why?", ultra-small packages like this are popular in JS because of the lack of a standard lib. Lots of devs prefer to install a dependency for each one-liner utility rather than write them themselves. The only added value of those packages is that they're usually unit-tested against weird edge-cases that you might miss if you wrote them yourself. Edit: related discussion at https://news.ycombinator.com/item?id=20223190 https://news.ycombinator.com/item?id=20223190
    - TAForObvReasons 7y ago
      the small libraries are best compared to stackoverflow code snippets. Instead of reading and copying a solution that may be out of date, you can use a (theoretically) tested solution that receives bug fixes. In many ways it is superior to the copy and paste of lore

DangitBobby 7y ago

I need to publish it publicly to install it via pip, npm, cargo, etc. for public use.

mroche 7y ago
Pip does not need a package to be public in order to install it at all, I’ve installed plenty of packages from tarballs and directories just fine. From the docs[0] Install packages from: - PyPI (and other indexes) using requirement specifiers. - VCS project urls. - Local project directories. - Local or remote source archives. Although I’m not quite sure how you’re using “for public use” in that sentence. [0] https://pip.pypa.io/en/stable/reference/pip_install/#id19 https://pip.pypa.io/en/stable/reference/pip_install/#id19
- DangitBobby 7y ago
  I meant to say private use, not public use. But if I want to install from pip over the internet, which is my most common use case it needs to be publicly accessible, right? Which for me means GitHub, bitbucket, pypi, or some other bespoke solution just to avoid "publishing" something for my own private use. Or do I misunderstand?
  - lionyo 7y ago
    You can publish to a local instance of PyPi https://www.linode.com/docs/applications/project-management/how-to-create-a-private-python-package-repository/ https://www.linode.com/docs/applications/project-management/...
    - DangitBobby 7y ago
      I could do lots of things that would be unnecessarily burdensome for the dubious benefit of having my package unpublished. If it's acceptable to install it on a local network I can just do it directly from a normal filesystem.
  - JimDabell 7y ago

wolco 7y ago

"sure: it is totally their fault for deploying something without carefully reading your code to figure out that it was a bit shitty beforehand" Yes you must read and understand everything or have trust in the publisher. Relying on the package name is going to get you in trouble. Sounds like a great exploit opportunity.

sabas123 7y ago
What if I have no reasonable way of fully understanding the code nor being able to judge the author on their trustworthiness (even disregarding that this isn't constant). As a community we need to accept that the above mentioned DOES happen. Pretending otherwise only hurts us all.
- TeMPOraL 7y ago
  > As a community we need to accept that the above mentioned DOES happen. Pretending otherwise only hurts us all. In fact, it happens very often when people are learning and exploring. So imagine I publish my shitty library "with a generic name and a description talking about how awesome it is". Imagine you're trying to learn $language. You buy into my deception and try to use my library. You get burned, and might be left with an impression that $language or its ecosystem is shitty, and never return, despite the fact that $language would suit the kinds of problems you're solving really well. If it happens enough times with enough libraries, $language may get a bad reputation. Preventing this becomes a matter of protecting the common good.
  - bigiain 7y ago
    Hands up everybody who remembers "Matt's Script Archive"? (Hmmm, just the greybeards. I could have guessed that I suppose...)
- watwut 7y ago
  One way to judge that is by whether the project was consistently maintained, what kind of issues are reported and if the important ones are fixed. So if the project seems to be ignored (no issues), if it has tons of them and no response, you won't use it or use it only with caution. Newcomer to langue or ecosystem should use popular frameworks and libraries, so that there is help available.

enraged_camel 7y ago

The way I look at it is that releasing an open-source library is like bringing a child into this world: its utmost well-being is your responsibility. If you don't have the bandwidth for that, don't publish it. And, if your circumstances change later, find another maintainer -- after all, you wouldn't just abandon your child on the street, would you?

ProZsolt 6y ago
It's not a child. It's a hammer. Somebody put it in the community shed so others can use it. If it breaks or somebody needs a nailgun, that's not their problem. I'm glad if somebody lent me their hammer so I don't have to buy one, even if it's not the best.

matheusmoreira 7y ago

> it also can simultaneously be not OK for you to publish it in a package directory with a generic name and a description Package repositories can be open to all developers or curated by software distribution maintainers. Being able to publish an open source project without dealing with Linux distribution maintainers is a major selling point of programming language package managers. Why even let people publish packages if they're not meant to? > 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? Absolutely. Using someone else's code means implicitly trusting them. Everyone should at least check out the package's source code for quality, sanity and signs of maintenance.

Vinnl 7y ago
> Why even let people publish packages if they're not meant to? I don't think GP even so much as insinuated in their post that people aren't meant to publish packages in general.
- matheusmoreira 6y ago
  The argument was: only packages which are good enough for production use ought to be published on official package repositories. This allows people to assume that all packages on the repository are stable, well maintained, good quality software without manually verifying each dependency. So why even let random people sign up a developer account and publish packages? Maybe they need a separate curated "serious packages only" repository.
ex_amazon_sde 7y ago
> Being able to publish an open source project without dealing with Linux distribution maintainers is a major selling point of programming language package managers. This is how disasters like leftpad happen. The bar for publishing software is extremely low and we pay the price every day in terms of security, bloat and complexity.
- watwut 7y ago

fendy3002 7y ago

I agree with readme needs to specifically mention unimplemented features. But the responsibility for using an unpopular library lies fully on the user, not author. Of course if the library is popular, author needs to maintain it, or delegate auhority to other maintainers. As user, it's clear that you need a feature which you found on an unpopular library. Now rather than be skeptical and research the library, or wrap it under yours so you can replace it later, or develop your own, you decide to blindly use it and blame the author.

bigiain 7y ago

There's a license for that: http://matt.might.net/articles/crapl/ http://matt.might.net/articles/crapl/ I know free software debaters and open source license philosophers love to hate on this one, but the fundamental core concept of "more importantly, it should absolve authors of shame, embarrassment and ridicule for ugly code" in the context of them choosing to release code or not is a great idea I reckon. (But I agree wholeheartedly with the thrust of your argument, and am of the opinion that if you spent more time on the logo design or website marketing copy for your library than you did writing the code, then "You're doin' it wrong...")

anticensor 7y ago
> 1. By reading this sentence, You have agreed to the terms and conditions of this License. The craziest click-to-accept clause I have ever read.
- bigiain 7y ago
  Alternatively, most obvious joke license ever... (or in retrospect, perhaps "equivalently" rather than "alternatively")
- jessaustin 7y ago
  Thanks a lot guy! By pasting that awful sentence into this thread, you've forced all of us reading here to agree to the license!

dunkelheit 7y ago

Agreed. People who demand free labor from open-source maintainers get a lot of deserved flak lately, but it is not that project authors are always blameless. Everyone who publishes some code for others to use faces a dilemma: they want their project to be popular (because being associated with a popular project is prestigious), but popularity means that the project demands additional effort to polish it, deal with bug reports and pull requests etc. So there is a temptation to convey the appearance of maturity without putting in the required effort. So yeah, it is totally OK for your open source library to be shitty, but please state this clearly in README to save everyone's time.

AnIdiotOnTheNet 7y ago
I agree. If you are actively marketing a project, you are declaring yourself open to criticism. You don't get to play the "what do you want for free?" card and say "my thing is totally awesome and you should use it!" at the same time.
- cycloptic 7y ago
  Yes you do. I do that all the time. It just depends on who you're talking to. You can usually tell within a very short period of time who is going to get invested and add value, versus who is going to fall behind and demand a disproportionate amount of attention.

asadjb 7y ago

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 7y ago
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 7y ago
  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 6y ago
    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.

fudged71 7y ago

Do package directories have moderators? The naming problem has always interested me

Matthias247 6y ago

> 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: I'm observing this regularly. Currently a bit more in the Rust community since I'm more active there, but I think it's a thing that happens everywhere. I think in most situations it happens is is incidentally: The people who wrote those packages do not actually have the experience to observe design and quality issues in their package. They might still be in university, or have a minimal amount of industry experience, and found working on an open source project to be a nice way to be creative. And in one metric that they found for themselves, the might even beat very established projects - let it be performance or finding the new "ultimate abstraction". Therefore they are going forward to market the project as the awesome new thing - without knowing about other important metrics that their project does not meet. I'm not sure how this can be improved. I think it would require experienced reviewers and curators that are willing to look into other peoples open source projects and help them. As well as authors of those projects to be willing to be mentored. Both is not easy. As an experienced engineer you have enough to to that you don't want to look into YetAnotherProject. As someone who wants to hack on a side project as much as possible you probably don't want to waste your time with talking to someone else.

m463 6y ago

caveat usor

mozilianulb 6y ago

Nice