91–100 of 364 posts
Earlier quoted context omitted.
I need to publish it publicly to install it via pip, npm, cargo, etc. for public use.
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.
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?
https://github.com/franciscop/picnic/pull/203/files
+If you spot a bug or any other issue you may go to hell because this software is officially Bug Free(TM). +
Similarly with an open source libs or utils. If it's shitty by your own admission, then either keep it to one-self or properly warn people that it's just that ... shitty, not MIT kind of AS-IS.
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 a…
EDIT: Not sure why this was downvoted, maybe people forgot that padStart and friends appeared in ES2015, long after left-pad was created
Missing (2015), though the message is timeless.
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…
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.
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.
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…
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…
I've used and been the maintainer of a "shitty" open source window manager off and on for the last 10 years. I love the project. People at my last few companies joke about it. But it's so fun. Who cares if it's shitty. Ride bikes and write code.
This comes down to releasing an MVP so you can find out what people want and iterate. If your project is actually viable and interesting to people, you'll get a lot of useful feedback a lot quicker than you would if you sat around "perfecting" it.
A big point: there's an anecdote about a Hungarian economist who, when asked "how are you?" would reply "compared to what?". Sometimes a 'shitty' library is only 'shitty' in your head compared to some idealized picture of what 'good' might be. We had commercial success with Hyperscan (back when it was a closed-source library) when it was in a state that was Truly Shitty as compared to how it is now (actually, even a couple years later it was much better). However, the question "compared to what?" was important - it was way better than anything else that solved the same problem (including custom regex hardware). So we made a good chunk of money with a "shitty" library.
It's important to be honest about what your answer to "compared to what?" is, the state your library is in, and how much work you plan to do, though. I'm not crazy about the temper tantrums people throw about this ("how dare you TRICK me into using your free library") but it would be nicer if people were to use 0.1-type version numbers and words/phrases like "experimental" or "hobby" or "I wrote this for a lark" a bit more freely.
If you're planning to win in some 'niche', please make that clear - Hyperscan was the best available multi-pattern streaming regex matcher at the time, but it would have been a dreadful substitute for libpcre if you wanted a featureful single-pattern non-streaming regex implementation.