Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

drmaciver.com

Post reply on HN
Print view View original

241–250 of 364 posts

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

#241

Post by wizzwizz4 »

guygurari wrote: post #184
ljm wrote: post #180

Earlier quoted context omitted.

If anyone is in any doubt about this, I would like to point them towards this github issue: https://github.com/mrc-ide/covid-sim/issues/165

I don’t doubt it, but covid-sim is not the best example of this effect. In this case, people are worried that poorly written simulation code is informing policy decisions that affect billions of people. They are not demanding that it should be fixed, they are demanding that it should not be relied on in its current state.

They're worried that there isn't testing code to prove that it's correct. If it's proven correct in other ways, it doesn't need unit tests.

Yeah, the code's bad – so what? It wasn't written by programmers. Most simulation code is bad, but if it's been proven correct it doesn't need to be good.

From what I can tell, this is a matter of conflicting conventions in different fields meeting head-on.

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

#242

Post by beart »

conroy wrote: 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”.

Is there anything preventing you from adding other maintainers to the project?

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

#243

Post by wolco »

bigiain wrote: post #160
wolco wrote: post #96

Earlier quoted context omitted.

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

I would like to draw to your attention the magnitude of that task, with a recent link from another HN comment discussion: http://npm.anvaka.com/#/view/2d/react-native and https://github.com/microsoft/react-native-windows/blob/maste... Turns out left-pad.js is on line 8571 of that 14+k line yarn.lock file. How many React Native developers do you suppose have reviewed every line of code in every library referenced in t…

In react's case you put your trust in facebook and because of the size most issues get discovered and someone has an article on how to fix before breakfast.

When you include left-pad in your own project you should audit it. In the end you are the only line of defense. With react it's larger so you can trust others.

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

#244

Post by cellularmitosis »

chadlavi wrote: post #229
cellularmitosis wrote: post #179

Earlier quoted context omitted.

At scale, how do you tell the difference between software which is finished vs software which is unmaintained?

"Finished software" is a myth.

Though I love a good fatalistic Jamie Zawinski reference, I’ll resist and stay on-topic. I think you mean “for the kind of software I typically get paid to write, software is never finished.”

However, if you widen your perspective a bit, you’ll find plenty of examples. I assure you, “space invaders” was finished in 1978, and it will never see any “maintenance”.

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

#245

Post by xwdv »

CalRobert wrote: post #210
Justsignedup wrote: post #89

I once wrote a library in backbone.js to have a data-synchronized list. It allowed me to provide an array, and it'll keep that array sync'd up to what I saw. I had a kid and a fulltime job and going through a divorce. I happened to use it at my job, but everyone kept asking for me to integrate it into new up and coming repos which I didn't have time for. Honestly I felt bad about not caring, but the reality is that I…

Unfortunately, DINKs are hard to compete with professionally. Old boss used to loudly thank my colleague for doing tickets on the weekends, and too often people seem to assume I want to spend my weekend "brushing up" on some implementation detail for a project I don't care about. Even "why doesn't he come to after work drinks?" Is hard to answer with "because my spouse is _also_ an exhausted wreck at the end of the d…

Do you ever just tell them that? You will get no respect until you do, in no uncertain terms. Otherwise, you will be walked all over.

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

#246

Post by cellularmitosis »

wpietri wrote: post #235
cellularmitosis wrote: post #175

Earlier quoted context omitted.

I will never understand this point of view. The author has already given you possibly hundreds of hours of free labor simply by publishing the project. But now, because they won’t give you a few more, they’re a douchebag? Even if they close all issues with no comment, they have given you a such _massive_ head start vs having to write the entire project yourself from scratch. How can you be anything but grateful?

If they have it open for issues and then handle the responses they have invited poorly, then yes, that's rude. A douchebag doesn't magically stop being a douchebag because they've open-sourced some code.

fair, I actually didn’t know you could disable issues.

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

#247

Post by [deleted] »

stevenwliao wrote: post #197
wolco wrote: post #96

Earlier quoted context omitted.

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

Who has read through all the code of their direct dependencies, let alone transitive ones?

[deleted]

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

#248

Post by franciscop »

growse wrote: post #176
freedomben wrote: post #51

Earlier quoted context omitted.

Did you tell them why you were closing the issues as #WONTFIX? I maintain a few projects in the "hundreds of stars" range, and I also send PRs to numerous projects with regularity (I make a point to fix typos and such in documentation when I find them). Of course some people are low effort issuers, but some people put time and effort into opening an issue on a project. When the maintainer closes it without even takin…

> Of course some people are low effort issuers, but some people put time and effort into opening an issue on a project. When the maintainer closes it without even taking 60 seconds to type a quick message why, it shows me that the maintainer is the entitled dick, not the user. So what you're saying is that if a person puts a lot of time and effort into opening an issue, they're entitled to a response? The maintainer…

When I see someone expects/demands something of me, I point them to the permissive MIT license. I am also a Spaniard living in Japan, so the concept of "social norms/expectations/etc" (whatever that even is) is totally meaningless to me.

If you put some effort and need help with the project, I'll try my best to help you. If you come demanding free support for your project, I'll just close the issue saying this is not the place.

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

#249

Post by BurningFrog »

CalRobert wrote: post #210
Justsignedup wrote: post #89

I once wrote a library in backbone.js to have a data-synchronized list. It allowed me to provide an array, and it'll keep that array sync'd up to what I saw. I had a kid and a fulltime job and going through a divorce. I happened to use it at my job, but everyone kept asking for me to integrate it into new up and coming repos which I didn't have time for. Honestly I felt bad about not caring, but the reality is that I…

Unfortunately, DINKs are hard to compete with professionally. Old boss used to loudly thank my colleague for doing tickets on the weekends, and too often people seem to assume I want to spend my weekend "brushing up" on some implementation detail for a project I don't care about. Even "why doesn't he come to after work drinks?" Is hard to answer with "because my spouse is _also_ an exhausted wreck at the end of the d…

> Unfortunately, DINKs are hard to compete with professionally

Sure, but people with kids win at life.

Let the DINK make some extra money. You still have it better.

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

#250

Post by grayclhn »

koheripbal wrote: post #13
dnautics wrote: post #5

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

Should I remove all the "TODO:" lines first?

No — they’re useful for you (presumably) which is enough reason to keep them. But they’re useful documentation too. I’ll usually search for “todo” as part of evaluating a library because it highlights what’s missing as well as the developer’s priorities and mindset.
Post reply on HN