Live data from Hacker News

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

drmaciver.com

151–160 of 364 posts

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

#151
post #87

I wrote a Python library that was pretty popular at one time. I gave a talk on it at PyCon, at one point it was in the top 200 most downloaded packages on PyPI. Since my employer told me I was no longer allowed to work on it at work, I have felt quite a lot of guilt about all but abandoning fixing bugs and reading the mailing list. I've been working on a "next generation" version, almost a rewrite, but I don't see a…

Have you put some disclaimer about your situation and said that this repo won't be maintained and feel free to fork? I think it'll be the best resolution for your situation.

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

#152

Earlier quoted context omitted.

I have few projects on 1k+ stars; the ones that are more beginner-friendly are normally where I get most unrelated requests. I used to help people where possible, but now I just don't have the time (or TBH, motivation). So I closed the issues on those two projects that got most low-quality issues. People started to open PR to tell me I was wrong and I should open the issues. This cemented my decision, oh the entitlem…

I think that's understandable. You closed issues for bugs you didn't resolve.

OP does not owe you their labor.

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

#153
post #5

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

Tend to disagree w.r.t. the disclaimer tbh. Be it GitHub or package manager of choice I don't get where the default assumption became "everything on here is curated and production ready" rather than "this is something a 15yo built 5 years ago while on shrooms". That's part of due diligence, if I use something that isn't explicitly marked as maintained or don't understand the state it's in that's on me imho.

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

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

There's a license for that: 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...")

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

#155

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…

Why would you feel bad? The whole point of open source is they could have done it themselves, if they wanted some integration they needed and you didn't. And then they could either contribute it back, fork your project or just keep it to themselves, if the license allows it. At any rate, you already helped them...

People often act very entitled about open source I've found.

You'll often get angry irate emails/issues raised demanding you help them or add a new feature or whatever. Some people are just clueless and need help, others are just dicks.

It is often not worth the hassle in my opinion, but then everyone's circumstances and motivations are different and I am glad that a lot of people do think it is worth it.

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

#156
post #143

Earlier quoted context omitted.

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?

You can publish to a local instance of PyPi https://www.linode.com/docs/applications/project-management/...

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.

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

#157
post #87

I wrote a Python library that was pretty popular at one time. I gave a talk on it at PyCon, at one point it was in the top 200 most downloaded packages on PyPI. Since my employer told me I was no longer allowed to work on it at work, I have felt quite a lot of guilt about all but abandoning fixing bugs and reading the mailing list. I've been working on a "next generation" version, almost a rewrite, but I don't see a…

Why would your employer decide what you do on your spare time?

Not everyone wants to (or is able to) to work on projects in their spare time.

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

#158

Earlier quoted context omitted.

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?

GitHub and Bitbucket have private repositories and you can install from those using pip. There's nothing forcing you to make something public.

I know about private repos. The hangup was installing from them. Last time I looked up how to have private python packages the the impression I got was "It's not possible." But now with a single Google search I see that it's very much possible (by using ssh). Not sure what changed other than two years have gone by.

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

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

There's a license for that: 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…

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

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

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

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 that file? (Or even how many engineering teams at any React-using Unicorn size startups or FAANG have exhaustively reviewed all those lines of code?)

Is FaceBook a "trusted publisher" of React? Is npm a "trusted publisher" of Node libraries? Was Azer Koçulu a "trusted publisher" of left-pad.js?

(And it's turtles all the way down. Is Microsoft a "trusted publisher" of Windows? Is Dell a "trusted publisher" of bios? Is Intel a "trusted publisher" of cpu micro-code? Is Western Digital a "trusted publisher" of hard drive firmware? Is every unnamed silicon manufacturer and pcb and subcomponent assembly house a "trusted publisher" of the embedded code in their network card/usb hub/battery management chip/whatever?)

I _do_ agree with you, but these days it's very difficult, at least in much/most of the software world, to determine the height of the people/libraries claiming to be "giants" offering their shoulders to stand on. (And like with React, it's more and more difficult to determine which actual giants are standing on bedrock, and which have a foothold with quicksand uderneath it...)

Post reply on HN