Live data from Hacker News

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

drmaciver.com

31–40 of 364 posts

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

#31

As both an open source author/producer and consumer, I wish more projects were forthright about: 0) known defects 1) when the author no longer uses the library themselves 2) the repo is abandoned and alternatives are not given There's a lot of abandoned code out there. It'd be nice if package managers had abandoned-package detection built-in.

The problem is that in practice there are many times that the visible different between "done" and "abandoned" is null, specially for smaller single-purpose libraries.

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

#32

Earlier quoted context omitted.

Problem is there's no auto detection that a repo is no longer maintained. Easy to do but github does not do it.

The first thing I do is just check commit history for recent commits. Usually a good indicator a thing is abandoned

How do you define if a small library has been stable for years?

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

#33

Earlier quoted context omitted.

I find the GitHub "archive repo" functionality a great, easy way to indicate a repo is abandoned; the most you need/have to do is a little readme edit/repo description edit if you want to explain or point to a good alternative.

Problem is there's no auto detection that a repo is no longer maintained. Easy to do but github does not do it.

[deleted]

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

#34
post #14
post #5

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

Unless you have something specific to point out / warn users about, why? It is what it is, and unless users contribute something back to make it better, it's cost them nothing. If they did contribute something back, then hopefully it's a little less shitty. Unless the library in question is objectively bad and/or non-functional, no apologies or disclaimers are necessary.

Why not? Sticking a disclaimer saying "this has basically no test coverage" at the top of your readme has negligible cost and might stop someone from being fired.

Of course, there's no obligation or even expectation that you should provide such a warning, but if you're already thinking about it, might as well just do it.

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

#35
post #25
post #5

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

There's also different "shitty"'s. Some are only aesthetic/architecture features like bad CSS or a kooky object model or API or performance problems or something, but some have security vulnerabilities.

Absent an audit for a specific version of a library, you probably shouldn’t assume any random package you use is secure.

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

#36

As both an open source author/producer and consumer, I wish more projects were forthright about: 0) known defects 1) when the author no longer uses the library themselves 2) the repo is abandoned and alternatives are not given There's a lot of abandoned code out there. It'd be nice if package managers had abandoned-package detection built-in.

I’d disagree with point 2. There shouldn’t be any responsibility for a (ex-)maintainer to provide alternatives themselves; especially when there may not be any at point of abandonment .

Is there significant value to maintaining a set of glorified search engine results in a README? It means the list of alternatives then have to be maintained in case they too are abandoned.

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

#37

But when potential employers come looking at your work they'll say "hey this code is shitty! It's not a work of art with 100% code coverage tests and perfect in every way. We can't possibly give you a job. Every line of code in our corporate repo is Mona Lisa quality, we can't let rubbishy developers like you in."

The first thing you learn when you're proud of your Github profile is that nobody is actually clicking into your projects and reading code, with few exceptions. Sure, at small companies where developers interview you, or maybe if you link to a specific relevant project in your cover letter, you might get a pair of eyeballs. But I think people vastly overestimate the readership of their repos when looking for jobs.

I like to think of it as Linkedin for coders.

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

#38
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…

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

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

#39

I had a GitHub project that got a few hundred stars. The amount of mean, crazy, and entitled people is crazy. I have no idea how the bigger projects can deal with it.

I agree it's an audience problem. I had a Wordpress plugin up and I'd get all sorts of entitled requests, borderline "plz fix my website you broke it".

But also had some C libraries for Arm STM32 and only ever got solid pull requests and people eager to help. You see the same thing in IRC / Discord channels of those technologies.

Post reply on HN