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…
It’s OK for your open source library to be a bit shitty (2015)
151–160 of 364 posts
Re: It’s OK for your open source library to be a bit shitty (2015)
#152Earlier 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.
Re: It’s OK for your open source library to be a bit shitty (2015)
#153As the author of shitty open source libraries I agree, but a bit of a disclaimer in the readme should be expected.
Re: It’s OK for your open source library to be a bit shitty (2015)
#154I 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…
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)
#155I 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...
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)
#156Earlier 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/...
Re: It’s OK for your open source library to be a bit shitty (2015)
#157I 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?
Re: It’s OK for your open source library to be a bit shitty (2015)
#158Earlier 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.
Re: It’s OK for your open source library to be a bit shitty (2015)
#159I 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…
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)
#160I 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.
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...)