Live data from Hacker News

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

drmaciver.com

131–140 of 364 posts

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

#131

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.

> There's a lot of abandoned code out there. It'd be nice if package managers had abandoned-package detection built-in.

Dart's pub.dev does! All projects get scores for Popularity, Health and Maintenance.

Here's a random example:

https://pub.dev/packages/redux#-analysis-tab-

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

#132
post #14

Earlier quoted context omitted.

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.

I see nothing wrong with a disclaimer along the lines of "This is a hobby project. As the author I care about this project and want it to be as good as possible but don't expect the kind of polish you'd see in projects with corporate backings." It doesn't discredit the project in any capacity, it just tempers users expectations.

But this is clearly the default situation for any project not hosted under an organisation.

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

#133

Earlier quoted context omitted.

Do you ask to look at their github? If yes, then what's the point if you're not trying to see the quality of the code and the tests?

I’ve evaluated GitHub profiles and contributions in the past. As long as there’s a body of work with reasonable complexity and no big red flags like a nasty argument or a bug-riddled PR, I consider it a positive signal that they can code. I specifically look at their opened issues and PR’s, rather than their commits, as a way to gauge their ability to code in a team setting. I won’t try to guess how good they are at…

How do you differentiate between "reasonable developer, can deal with complexity" and "extremely good developer, will dramatically improve the codebase and produce less technical debt"?

Does the distinction matter at your company, or is the primary metric "good enough"? Is this industry standard, or does it vary by company?

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

#134
post #5

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

Here's one of mine in the README:

Warning:

[ShittyFrameworkName] is just a personal toy framework:

* It will break compatibility from commit to commit with no warning whatsoever.

* It has (almost) no tests

* It has (almost) no documentation.

* It's (mostly) not php-fig friendly

* Its code only cares about the needs of its author

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

#135
post #6

I maintain an open source project with ~2k stars ( https://github.com/kyleconroy/sqlc ). There’s a large list of bug reports and feature requests, but since I don’t work on it full time, I’ve gotten really good at saying “No” and “I’m sorry”.

You can probably leave the sorry part out. There’s nothing to be sorry about :-)

Text is ambiguous, overtly communicating that you aren't trying to be mean is a good idea IMO.

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

#136
post #96
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…

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

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.

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

#137
Thanks so much for saying this. Those thoughts hold me back when I'm thinking about starting an open source project. I already do lots of coding at work. I'm single and no kids, but spending a large amount of time on it in my free time would totally wreck my balance. I love coding but I also need non-technical activities in my life.

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

#138
post #107

Earlier quoted context omitted.

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?

You can for sure with go

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

#139
post #63

If you find an open source library that could be better, and you are using it, make it better yourself.

This is naive. If it's a bad library full of bugs, it's going to be garbage code. I'm not going to spend inordinate amounts of time & effort wrestling with shitty code to earn the right to say the library is bad. IMO that's not a good standard.

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

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

Why not checking the contributors instead of the forks? Just pick the most regular ones, or the ones that contributed the most (in number of PRs).
Post reply on HN