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 didn't. I had other things on my mind.
Some people are DINKs (dual income, no kids) and get bored so instead of video games they'll make a side project. Some people have totally other circumstances. For me I wanted my spare time to either zone out to some games, or zone in to spending time with my daughter. I had plenty of coding to do at work.
I've seen places where working on your free time and/or weekends would be totally frowned upon by managers, and the general culture around workers would be that working on weekends is giving up your time for free in an attempt to clib on the other's backs, so that wouldn't be very popular among your colleages.
I have no children. I like my job. I spend my free time doing things that aren't software development.
I theoretically could work outside of work hours, sure, if I were a boring person with no interests.
I think that most people who treat their jobs as their 'calling' and burn themselves out on them ruin the world for both themselves and the rest of us. Races to the bottom everywhere.
It doesn't bother me too much though, since ultimately the selection pressure is such that the brown-nosers end up being abused by their managers whilst the stubborn lot get promoted. YMMV.
My American boss regularly feels proud that he puts in 12-14 hour days. In my opinion, that amount of hours makes sense if I am working on my own business or something that truly benefits humanity (like a vaccine for COVID-19 for example). It is hard to do good work more than 6-7 hours per day anyway and much harder to sustain it for long periods of time
Sure, but people with kids win at life.
Let the DINK make some extra money. You still have it better.
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.
Absolutely, but that is often not the expectation. When I have pointed this out in the past people have gotten hysterically angry demonstrating a degree of entitlement. The mere mention they could do it themselves or submit a pull request has been regarded as a hostile personal insult like declaring war or perhaps worse than making sexually profane and racial commentary about their spouse.
1. Allow others to step in as maintainers and review/approve new features and bug fixes in your stead.
or (if you want to maintain control of your library)
2. Be clear that your library is in maintenance mode, and encourage and bless (by linking from your README) a fork (or forks) that work for those who were using your library but want the extra features that you don't want or have time to implement in your library.
Otherwise your project is actively getting in the way of the community organising development of similar.
If you had to go to the trouble of creating your library in the first place, it means either
A) "the community" had not met your specific need, so why would they start now? Or
B) you did this for fun/learning/visibility/coping with a mania, in which case you still don't owe us any favors.
That said, doing either of the above would be nice and appreciated, but you don't have to donate anything above and beyond what you are have.
If there's an implicit obligation, it seems to me it's on users, not authors. If you really need something changed you should fork/fix it yourself or talk somebody else into doing it. That right is baked into every major OSS license.
And that's taking into account we're the lucky ones that can work from home and keep getting a salary
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.
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...)
As a community we need to accept that the above mentioned DOES happen. Pretending otherwise only hurts us all.
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 against obvious click grabbing projects (like is-odd, is-even, leftpad...), but it's also on the JS standards committee to develop a standard library that doesn't need 1 or 2 line dependencies to function the way a reasonable human would expect it to function.
> sure: it is totally their fault for deploying something without carefully reading your code to figure out that it was a bit shitty beforehand... but should they really have to do that?
Yes, you should at least read through the README and take a look at the issues before using any project. Code with 0 issues filed, no forks, and no stars...should not be used in production without proof reading. You can get a benefit of the doubt if it's clearly a popular project (i.e. apple/swift, google/flutter), because at least then you know multiple people before you have tried it out and been satisfied enough to want to help out.
> if you bring something that you know tastes bad or will make someone sick to the potluck and put a little sign on it saying "gourmet enchiladas: much better than what you get at the store" and put it in the center of the table, it is still a problem
The problem is that this is subjective. What does "tastes bad" mean? Are you expected to know what will make someone throw up? Sure, you'd be a dick for serving raw chicken - but the raw chicken projects generally don't have READMEs in the first place, because they were never intended for usage by others. It's your fault if you incorporate raw chicken into your meal and get sick from it.
The problem is that some people view a package manager as a farmer's market while others see it as a restaurant. Should you serve gourmet meals, or are berries OK too? If you sell raw chicken at a farmer's market, it should be obvious to the consumer that they have to cook the chicken first before eating it. The problem is when a customer goes to a farmer's market expecting it to be a restaurant and gets sick from something they didn't understand.
EDIT: Not sure why this was downvoted, maybe people forgot that padStart and friends appeared in ES2015, long after left-pad was created
I'm observing this regularly. Currently a bit more in the Rust community since I'm more active there, but I think it's a thing that happens everywhere.
I think in most situations it happens is is incidentally: The people who wrote those packages do not actually have the experience to observe design and quality issues in their package. They might still be in university, or have a minimal amount of industry experience, and found working on an open source project to be a nice way to be creative.
And in one metric that they found for themselves, the might even beat very established projects - let it be performance or finding the new "ultimate abstraction". Therefore they are going forward to market the project as the awesome new thing - without knowing about other important metrics that their project does not meet.
I'm not sure how this can be improved. I think it would require experienced reviewers and curators that are willing to look into other peoples open source projects and help them. As well as authors of those projects to be willing to be mentored. Both is not easy. As an experienced engineer you have enough to to that you don't want to look into YetAnotherProject. As someone who wants to hack on a side project as much as possible you probably don't want to waste your time with talking to someone else.
If I've built a small library that does something useful for my set of needs, it's not crap software. It works perfectly well for my needs.
If someone then goes ahead and uses my library, without understanding what needs it satisfies and what it does not, how is that on me?
I release it to the world with the understanding that someone else might have the same requirements that I had when I built it. Why shouldn't I have released it?
As an extreme example consider content farms like eHow. After all, they simply publish some low-quality how-to guides, no one is obliged to read them. Why then are they so universally reviled?
> If someone then goes ahead and uses my library, without understanding what needs it satisfies and what it does not, how is that on me?
Being upfront and clear about the needs it satisfies is good documentation practice and plain common courtesy. If you did it and they still misunderstood, then yes, it is on them.
I second the comment above about having a honest description to waste other people’s time.
So yeah, it is totally OK for your open source library to be shitty, but please state this clearly in README to save everyone's time.
As user, it's clear that you need a feature which you found on an unpopular library. Now rather than be skeptical and research the library, or wrap it under yours so you can replace it later, or develop your own, you decide to blindly use it and blame the author.
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://pip.pypa.io/en/stable/reference/pip_install/#id19
Package repositories can be open to all developers or curated by software distribution maintainers. Being able to publish an open source project without dealing with Linux distribution maintainers is a major selling point of programming language package managers.
Why even let people publish packages if they're not meant to?
> it is totally their fault for deploying something without carefully reading your code to figure out that it was a bit shitty beforehand... but should they really have to do that?
Absolutely. Using someone else's code means implicitly trusting them. Everyone should at least check out the package's source code for quality, sanity and signs of maintenance.
I don't think GP even so much as insinuated in their post that people aren't meant to publish packages in general.
This is how disasters like leftpad happen.
The bar for publishing software is extremely low and we pay the price every day in terms of security, bloat and complexity.
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...")
The craziest click-to-accept clause I have ever read.
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.
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 entitlement of some people.
But also had some C libraries for Arm STM32 and only ever got solid pull requests and people eager to help. You see the same thing in IRC / Discord channels of those technologies.
which will be interesting to see if you ask them for payment for fixes, would they pay?
I think a lot of this has to do with the effort you put into community management. We put tons of energy into making it easy to make good contributions: PR/issue templates, we're on slack, we respond to emails, we make it as easy as possible to get your code in as long as it passes tests. It's a lot of effort and I can't imagine doing it for something that was just a personal project, but I think that's how the bigger projects deal with it.
This is besides my fulltime job, friends and hobbies. So I don't really have much time for growing a community, I've done some effort in the past when I had more time and it worked fairly well, but I found it to be very project-oriented in general so if you do many smaller projects (as opposed to few large ones) the community approach doesn't scale well.
I don't encounter many mean/crazy people! I can count them with one hand. I find few entitled people, but most people I've found are nice.
If it's a user-facing project, then people will approach the project's "github issues" as a company's support line, and feel a bit more entitled.
If it's a library or plugin for developers, people generally have more empathy and appreciation towards the maintainers.
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.
Oh boy you'd have thought people had paid thousands of dollars for the code the way people talk to the maintainers.
The one thing that gives me pause is the prospect of having to manage a bunch of unfriendly feature requests and bug reports. Here's hoping we find ourselves in a virtuous niche.
It's about time that programmers recognize that a "Delete GitHub" movement is as valid and as needed as "Delete Facebook" or "Delete Twitter".
GitHub is not really about software development. GitHub is yet another social networking site, only it's for busywork masquerading as Real Important Programmer Stuff.
Essentially; do publish all work you possibly can, simply be clear about what the software does or does not do.
I am very guilty of not doing this myself. I throw together some bit of code that is useful to me, and dump it on github with no explanation of what it does or how to use it.
As a bad example, I'd encourage everyone like me to put in a bit of effort to explain what your code does, so that when someone stumbles across it they have a way to give it a try and see it doing something.
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.
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 clear path for releasing it in a way that helps people still using the current version.
It may be self-serving, but I am really going to try to take this essay to heart, and not beat myself up everytime a weekend goes by that I don't spend working on my project.
"You should rewrite in" / "Why does't it do" / "Make it do".
It's nice that people are using it. I generally (try to) assume this is a language/cultural thing, and people don't realise that they're coming across as a bit rude in English.
But, it would be nicer if people approached commenting on OSS by first thinking "Author is doing this for fun, unpaid, and I'm getting something nice out of his/her time", THEN writing their comment.
I'd get the same issues raised, and that's fine. But the language might read a bit nicer.
One thing I would like to suggest is to have a question in the feature or bug issue template to ask what people use the lib for and what they like about it. Maybe even set expectations.
I think there's a lot of scope for changing the way that comments on issue trackers and pull requests are taken in order to make the interactions more human and friendly.
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.
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.
It's uncommon (and my anecdote is part of the "exceptions" for sure), but it's very very motivating when it happens.
On multiple occasions I've had to talk them out of not wanting to even interview based on one random file in a random repo by the interviewee.
Because of this, when I start applying I hide all my repos that I'm not mostly proud of.
I wouldn't want to work there and they would have saved me so much trouble.
Bad GitHub code means nothing. Good original GitHub code means something. And the less these orgs realize that the easier it is to get engineers that are otherwise unappreciated.
Contrast this with the standard assumption - I'm using random code off the internet with a good faith effort by a maintainer not to break my stuff. If I find things broken, I may upstream a patch to said maintainer - or decide it's not for me and move on.
I never go through the latter effort when there is a big warning on the Readme.
Of course, there's no obligation or even expectation that you should provide such a warning, but if you're already thinking about it, might as well just do it.
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 assume they can use random code from random developers they never met without even looking at the source code?
And I might have a library that over the years changes from being shitty to high quality (and back!). I wouldn't want to go changing the licence to follow its lifecycle.
I think it would be valuable to have some widely understood conventions of text you can put in the README to set appropriate expectations.
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.
Because that's open source, and has worked well for a lot of things.
Warning:
[ShittyFrameworkName] is just a personal toy framework:
* It will break compatibility from commit to commit with no warning whatsoever.
* It has (almost) no tests
* It has (almost) no documentation.
* It's (mostly) not php-fig friendly
* Its code only cares about the needs of its author
Many of them are written in a way that is probably useful to another coder who is taking the time to look at that piece of code — whether because of an issue, or for 'fun'.
Try to send bug reports and look at how they fix it. Sometimes it is even difficult to find the file that must be fixed. Perhaps next time you spot a bug, it is in the same file and you can fix it.
Start with small changes, I recommend not investing more than one of two afternoons because the maintainer may not merge it. Perhaps because the code is bad, perhaps because it doesn't follow the (implicit hidden) spirit of the project, perhaps because the maintainer is a moron.
Try to follow the nearby code style. Each project/maintainer has preferences. If you break them, the maintainer may ask nicely to fix them before merging.
(If they are not nice, just forget about the project. You have lost only two afternoons.)
(Whitespace changes is a hot topic, try to avoid whitespace changes unless you know the local policy.)
That's why there are maintainers who will tell you what you should change in order for your patch to be accepted upstream. This happens all the time, just go and read the mailing list or active Pull Requests of the project. (This is a good idea anyway, as reading through pull requests and comments will give you a good idea how 'things are done' in that project)
And don't worry, most maintainers are usually very friendly to newcomers. :)
If you contribute something to the Open Source community that works and is useful, then you might find some people who really appreciate the effort you went to.
...regardless of code quality...
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.
Is there significant value to maintaining a set of glorified search engine results in a README? It means the list of alternatives then have to be maintained in case they too are abandoned.
Dart's pub.dev does! All projects get scores for Popularity, Health and Maintenance.
Here's a random example:
The product is dominant in seo and many django beginners and intermediate install it without looking at it.
But it has also languished for years and failed to get an important model rearchitecture after the author had to stop work on it.
Still, I see it as a great turnaround opportunity and I’ve already learned a lot about OS and the pressure of knowing people want code fixed.
I think this article is for the author, Luke, who made this for himself for Australian addresses when django was still a smaller framework.
But it is also for me as someone trying to get context on how it has languished so long, and motivation to steer this thing into a place where it into helping more people without undue pressure.
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.
And I guess I'd just like to add my two cents: sometimes your issues are not being adequately triaged because the project is using another system for bug tracking and the engineers are slammed fixing those bugs instead lol.
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.
> There is no obligation to free labour. Every hour you put in working on your project for free is a gift to the world. If the world comes back to you and says "You are a bad person for not supporting this thing I need you to support" then fuck them. If they want that they should pay you for it, or do it themselves.
I've had my Javascript canvas library "side project" on GitHub for seven years. In those 7 years I've had exactly ONE issue opened - which then got closed when the person who raised it worked out for themselves how to solve the problem they'd encountered.
Instead, people email me their questions - maybe a dozen of those over the years. They're usually really simple questions on how to do this or that using the library. I ask people to open an issue on GitHub for their question (because other people might find whatever answer I come up with useful) ... then I never hear from them again. I like to assume they solved the issue for themselves and don't need my help; others may choose to interpret the facts differently.
So I'd actually welcome people raising issues. It shows me that my "side project" is more than vanity, that people find it useful. And it would help improve the library because I can't think of every use-case or edge-case myself.
... But whatever happens, I'll still continue working on the library: some compulsions are beyond cure!
> I think of someone releasing open source software as a gift to the world, not as claiming a responsibility to maintain it for you. Some projects do claim that responsibility, but it’s not automatically conferred just because someone released a project on GitHub. I think much more of the responsibility falls on the person using it.
However, we live in such paranoid times, that if you do release a project and don't open source it, people will immediately convince themselves and others that you've bundled malware in it. It's a sad state of affairs.
Code well, or code badly, Open Source or don't. It's your life, do it your way.
You might release something as a side project of a hobby, but people will become angry with you if it doesn't do what's advertised. This is significantly amplified if you go out of your way to tell people the project exists, in the hopes of it becoming popular and used. It can't become popular if it isn't good enough. That's the same for many different disciplines and various subjective standards of "good." In the case of software correctness is often stressed, unless it's generative art or something. So by marketing something in the hopes of it becoming popular you obligate yourself to getting it to the point where it can become popular.
So it's about not looking arrogant by saying something is true about a project when it isn't.
The problem isn't as simple as "don't mind if it's bad." Your library could end up being used in hundreds of projects. People want continued maintenance in this case. They might start filing issues against your project because of unforseen downstream bugs. But you might not feel like maintaining it anymore. Motivations change. But you'd have to be careful if you choose to hand off maintenance, because this can happen: https://github.com/dominictarr/event-stream/issues/116
So it isn't just a case of whether or not the code itself is bad. It's also about how you market the code to others. Ward people away if it's not production-ready. Sometimes undersell and never oversell. Remove any reason for people's expectations to be out of sync with the actual quality. In the case of event-stream the old maintainer became relied upon and then made the incorrect decision of letting an untrustworthy person have access to the code.
And also make clear your motivations. The creator of uBlock Origin states he might get bored of the project and move on. Give yourself an escape hatch like this so you can excuse yourself if you believe you really can't find yourself with the will to keep working on it in the future.
As long as those expectations are very clear to anyone who uses your code, then it is okay for public code to be bad.
People never fail to impress me negatively.
If money ever changes hands with the author of that code, that's a different story. But if it's something free you just found, and you have never paid the author anything, then at most you can warn others to not waste their time. You are in no moral or legal position to demand anything.
Like not fixing it when you can or know better is not good, but in the meantime the code isn't going to be poetic and just write it already...
"Since you have arguments why it's shitty, I encourage you to use that knowledge to improve that library, since you're free to improve it"
This can include not just the time spent on code, documentation, tests, issues.
I guess, it would help other developers empathize better with individual developers who do it for no monetary gains.
there is already enough and more than enough amount of this type of projects.
PHP: it is OK to be a bit shitty. Javascript: It is OK for your type system to be a bit shitty. Javascript: It is OK for your semantic consistency to be a bit shitty. Java: it is OK for you syntax to be a bit shitty. Java: it is OK for your value semantic to be a bit shitty. MongoDB: it is OK for your design decisions to be a bit shitty. node_modules: it is OK to be totally shitty.
I could go on and on.
