Live data from Hacker News

It’s OK for your open source library to be a bit shitty (2015)

drmaciver.com

111–120 of 364 posts

Re: It’s OK for your open source library to be a bit shitty (2015)

#111
post #106

Earlier quoted context omitted.

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 create…

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.

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.

Re: It’s OK for your open source library to be a bit shitty (2015)

#112
post #107

Earlier quoted context omitted.

You can install directly from GitHub, bitbucket, etc. with pip, BTW. My point was that if I want to have packages for private use installable over the internet with package management tools for various languages, I have to put them on the public internet, or jump through some hoops.

Package management tools for both Rust and Go and JS do support direct github urls with minimal boilerplate. You have no reason to make something public unless you want to.

Oh you can use those tools with private repos?

Re: It’s OK for your open source library to be a bit shitty (2015)

#113
post #8

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…

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

Re: It’s OK for your open source library to be a bit shitty (2015)

#114

Earlier quoted context omitted.

I think that's the point. Maintainers have no obligation to do anything for anyone

No, there is no obligation. But there’s a thing called courtesy. And as humans there are certain social norms. If someone spams me, I will ignore or retaliate by reporting as spam. If someone sends a low effort question, I might politely tell them to rtfm. If someone makes an effort to articulate a problem, even if I disagree, I’ll try to give them a reasoned response. And if I genuinely have no interest in any inter…

So you agree that there is no obligation, then assert a set of social obligations that should be respected.

Do you see the contradiction here?

Re: It’s OK for your open source library to be a bit shitty (2015)

#115
post #8

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…

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

I like this a lot. Publishing open source libraries and using them in private projects is a form of dogfooding.

Re: It’s OK for your open source library to be a bit shitty (2015)

#116
post #106

Earlier quoted context omitted.

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 create…

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.

Literally what it says: 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

Re: It’s OK for your open source library to be a bit shitty (2015)

#117
post #105

Github can help with this situation a lot. Yes, people are free to write and abandon whatever they want, but once a library has had hundreds of dependent users, and the primary repo is abandoned / unmaintained, Github could do a lot to guide dependent users away to a better fork. Today though, every popular repo has hundreds of forks and there is no easy way to identify forks that are more actively maintained. I unde…

Yes, that would be really useful. Currently looking evaluating forks can be really a pain.

Re: It’s OK for your open source library to be a bit shitty (2015)

#118
post #5

As the author of shitty open source libraries I agree, but a bit of a disclaimer in the readme should be expected.

> a bit of a disclaimer in the readme should be expected

Every project already has these. They're in the license files.

> This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

This disclaimer is clear, self-explanatory, legally binding and a standard feature of all licenses. So why do people assume they can use random code from random developers they never met without even looking at the source code?

Re: It’s OK for your open source library to be a bit shitty (2015)

#119
post #41

Earlier quoted context omitted.

> I'd get all sorts of entitled requests, borderline "plz fix my website you broke it" which will be interesting to see if you ask them for payment for fixes, would they pay?

That’s exactly what I would do. It’s very similar to people asking you to fix their computer for free when you have tech skills. Ask money (even just 5€) and 90% of requests fade away. The one that remains are willing to pay (and more than a few bucks).

Are you saying you would solve all my sw problems for 5€? Deal! Let me send you this project I have... :) Be careful.

Re: It’s OK for your open source library to be a bit shitty (2015)

#120
post #106

Earlier quoted context omitted.

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.

Literally what it says: 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 mi…

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
Post reply on HN