Earlier quoted context omitted.
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.
Oh yes I didn't read well, my bad.
It’s OK for your open source library to be a bit shitty (2015)
161–170 of 364 posts
Re: It’s OK for your open source library to be a bit shitty (2015)
#162Earlier 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.
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.
> As a community we need to accept that the above mentioned DOES happen. Pretending otherwise only hurts us all.
In fact, it happens very often when people are learning and exploring. So imagine I publish my shitty library "with a generic name and a description talking about how awesome it is". Imagine you're trying to learn $language. You buy into my deception and try to use my library. You get burned, and might be left with an impression that $language or its ecosystem is shitty, and never return, despite the fact that $language would suit the kinds of problems you're solving really well. If it happens enough times with enough libraries, $language may get a bad reputation. Preventing this becomes a matter of protecting the common good.
Re: It’s OK for your open source library to be a bit shitty (2015)
#163Earlier quoted context omitted.
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.
> As a community we need to accept that the above mentioned DOES happen. Pretending otherwise only hurts us all. In fact, it happens very often when people are learning and exploring. So imagine I publish my shitty library "with a generic name and a description talking about how awesome it is". Imagine you're trying to learn $language. You buy into my deception and try to use my library. You get burned, and might be…
Hands up everybody who remembers "Matt's Script Archive"?
(Hmmm, just the greybeards. I could have guessed that I suppose...)
Re: It’s OK for your open source library to be a bit shitty (2015)
#164Earlier quoted context omitted.
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.
Alternatively, most obvious joke license ever...
(or in retrospect, perhaps "equivalently" rather than "alternatively")
Re: It’s OK for your open source library to be a bit shitty (2015)
#165Earlier quoted context omitted.
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.
> I'm not into js at all
Programming in JS is just this way.
I had to include moment.js yesterday just to format a date. Nothing fancy, but no easy way around it.
Re: It’s OK for your open source library to be a bit shitty (2015)
#166As the author of shitty open source libraries I agree, but a bit of a disclaimer in the readme should be expected.
> a bit of a disclaimer in the readme should be expected Every project already has these. They're in the license files. > This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This disclaimer is clear, self-explanatory, legally binding and a standard feature of all licenses. So why do people a…
>legally binding
Counterintuitively, absolute disclaimers of warranty aren't legally binding in many jurisdictions. So don't assume that you are legally absolved of any responsibility just in virtue of having this line in the license.
Re: It’s OK for your open source library to be a bit shitty (2015)
#167Earlier quoted context omitted.
The first thing you learn when you're proud of your Github profile is that nobody is actually clicking into your projects and reading code, with few exceptions. Sure, at small companies where developers interview you, or maybe if you link to a specific relevant project in your cover letter, you might get a pair of eyeballs. But I think people vastly overestimate the readership of their repos when looking for jobs.
I learnt this when I uploaded a project that claimed to do something but was only like 10% finished and you couldn’t run it. It got cross-posted across the internet and a ton of stars and even referenced in some else’s project repo as a competitor/alternative and reasons why theirs was better! This experience really made me smile. Nobody even tried to run it.
FWIW, stars on Github aren't means of expressing that you've tested and liked something; they're means of bookmarking interesting repos. So it's entirely plausible you got hundreds of stars and nobody ever run the project. Myself, I've stared close to 300 repos, and have run maybe a handful.
Re: It’s OK for your open source library to be a bit shitty (2015)
#168Earlier 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.
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.
One way to judge that is by whether the project was consistently maintained, what kind of issues are reported and if the important ones are fixed.
So if the project seems to be ignored (no issues), if it has tons of them and no response, you won't use it or use it only with caution.
Newcomer to langue or ecosystem should use popular frameworks and libraries, so that there is help available.
Re: It’s OK for your open source library to be a bit shitty (2015)
#169As 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.
The problem is that in practice there are many times that the visible different between "done" and "abandoned" is null, specially for smaller single-purpose libraries.
Or mature, stable ecosystems. People use Common Lisp libraries that haven't been updated in 20 years, because they work.
Re: It’s OK for your open source library to be a bit shitty (2015)
#170I had a GitHub project that got a few hundred stars. The amount of mean, crazy, and entitled people is crazy. I have no idea how the bigger projects can deal with it.
I was surprised to hear that many open source developers get so many 'mean and entitled people' complaining on their project channels. My project https://socketcluster.io/ has almost 6K stars on GitHub and all I only ever get are people praising it - Sometimes I worry that people may even be over-praising it and self-censoring criticism (maybe they just like me as a maintainer). I think in its 7 year history, I only remember 1 or 2 complaints out of a total of several hundreds or maybe thousands of feedback comments, messages or emails. I do appreciate criticism though and those few critiques have been valuable.
I think maybe it has to do with:
1. Hype.
2. What percentage of developers were forced to use your tool/library against their will by their employers or forced upon them as a dependency of some other tool.
If a project is overhyped, then developers will be disappointed by reality and they will complain. The best you can do is try to set realistic expectations.
If a developer was forced to use your library by their employer (or it was forced upon them as a dependency of another tool/library that they're using and your dependency was throwing some weird error) then they will also complain. The best you can do about that is try to make your library work 'out of the box' as well as possible and make it work well in as many environments and operating systems as possible. Regulating hype by setting realistic expectations can also help prevent employers from forcing their developers to use a library. You should use more technical terminology instead of business buzz words when describing your project. You want to attract developers, not project managers.