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

101–110 of 364 posts

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

#101

Post by DangitBobby »

mroche wrote: post #77
DangitBobby wrote: post #59

Earlier quoted context omitted.

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

Pip does not need a package to be public in order to install it at all, I’ve installed plenty of packages from tarballs and directories just fine. From the docs[0] Install packages from: - PyPI (and other indexes) using requirement specifiers. - VCS project urls. - Local project directories. - Local or remote source archives. Although I’m not quite sure how you’re using “for public use” in that sentence. [0] https://…

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?

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

#102

Post by franciscop »

sgillen wrote: post #60
noitsnot wrote: post #43

Earlier quoted context omitted.

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

Maybe you know the OP, but in my experience a lot of issues are not bug reports but very low quality, uninformed or unreasonable requests or questions. Like questions made about basic functionality that is answered in the documentation/faq, or requests for features that are completely outside the scope of the project. Another popular category is requests for basic education e.g. “how does DQN work?”. That’s fine if i…

Exactly this. Bug reports were very welcome! While I stated that the API would not expand any longer in some projects, I also considered coherent feature requests a positive, and normally suggested and guided those as a plugin that lives within their codebase.

The problem was when people came like "I am using this library, can you debug my code?" and pasted a 500-liner, or like "this doesn't work on my XYZ system, fix it", or when they were just rude or demanding.

I've met some wonderful people BTW, and would also not trade that for anything.

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

#103

Post by franciscop »

pkaye wrote: post #64
franciscop wrote: post #22

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…

> People started to open PR to tell me I was wrong and I should open the issues. Did those pull requests have code changes?

No

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

#104

Post by DangitBobby »

sgillen wrote: post #91
sanderjd wrote: post #79

Earlier quoted context omitted.

This is why I really liked the approach of using a github username as a namespace for rubygems, it lets you publish things but with some indication that it may just be for personal use.

I like that a lot! could work for personal python packages too.

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.

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

#105

Post by harikb »

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 understand it is a non-trivial problem, but hopefully Github has the talent to solve this problem.

At the very least they can make it easy to ignore forks where

1. changes have already been merged upline 2. forks that only have cosmetic changes of imports (happens a lot for Go repositories)

This will allow the developer to pass the torch, so to speak, to someone else willing to maintain their own fork.

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

#106

Post by vxNsr »

TAForObvReasons wrote: post #94
nexuist wrote: post #38

Earlier quoted context omitted.

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

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.

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

#107

Post by harikb »

DangitBobby wrote: post #104
sgillen wrote: post #91

Earlier quoted context omitted.

I like that a lot! could work for personal python packages too.

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.

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

#108

Post by Aeolun »

andrewstuart wrote: post #49
munchbunny wrote: post #42

Earlier quoted context omitted.

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…

I'm pretty cynical about how any code evaluation is done. Amongst the many many ways code evaluations fail, the worst and most typical IMO is that the evaluator has an air of superiority, who marks down things they don't understand, and thinks their own coding is that of an artistic genius, approaches the tasks with zero science or rigor and is unable to articulate anything hard to back up their vague assertions comi…

Honestly, since we hire everyone on as a contractor first, I generally tend to believe that they can code if it’s on their resume and they’re otherwise a decent person and able to work in a team.

If someone doesn’t work out we just let them go after half a year. So far that hasn’t actually been necessary.

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

#109

Post by enraged_camel »

saurik wrote: 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…

The way I look at it is that releasing an open-source library is like bringing a child into this world: its utmost well-being is your responsibility. If you don't have the bandwidth for that, don't publish it. And, if your circumstances change later, find another maintainer -- after all, you wouldn't just abandon your child on the street, would you?

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

#110

Post by pjmlp »

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…

I can fully related to you.

Whatever I put outside is more to keep HR happy when they ask for a github link than anything else.

It is all a bit crappy collection from university projects, or tiny stuff I did on side either to learn an algorithm or a quick and dirty solution for something.

The good stuff I rather do it at work.

Post reply on HN