22 ms·

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

650 points by mmcloughlin 6y ago

zoomablemind 6y ago
I've a little anecdote on this. Once at a community potluck, our table ended up with several wine bottles...but no corkscrew. I reasonably asked a neighboring table to borrow one of their own (nice ppl, but strangers). Well, nicely, they lent me some suspiciously plasticky version of a corkscrew, literally, the screw was made of some sort of plastic!). Shitty, in one word... Sure enough it snapped, the cork still stuck, I'm embarassed, offered the owner another wine bottle in apology. Had a laugh about it together and fun time. But it was a lesson on shittiness-in-disguise-of-utility. 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.
nerdbaggy 6y ago
I 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.
- WrtCdEvrydy 6y ago
  Honestly, always give them the "We'll review your PR once it's ready".
- sergiotapia 6y ago
  I have a pretty simple project with 2.4k stars, and have met nothing but good people eager to help, and bending over backwards to help me help them. My project's "niche" may have something to do with it.
  - hazz99 6y ago
    What is it / what niche?
    - deleted 6y ago
      [deleted]
    - sergiotapia 6y ago
      https://github.com/sergiotapia/magnetissimo https://github.com/sergiotapia/magnetissimo - niche is: "self-hosted apps"
  - marcandre 6y ago
    Application domain may have something to do with it, language also. As a maintainer of Javascript and Ruby libraries, the difference in entitlement and cluelessness is remarkable.
    - tonyedgecombe 6y ago
      The Ruby community has always struck me as friendly and welcoming.
  - klenwell 6y ago
    This is encouraging to hear. My company built a tool to improve website accessibility. It fills a niche. We're almost ready to open source it. Basically just need to make the Github repo public. 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.
- kick 6y ago
  You can just...ignore people, on the Internet. It's a really useful thing! Once you accept that not all requests/insults/questions/comments are equal, and some are drastically less valuable than others, it becomes pretty easy. The initial mental barrier you have to break to do so is hard to get around, though.
- gitgud 6y ago
  In my experience, it depends what the project is and who is attracted to the github issues. 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.
- smcameron 6y ago
  I have a github project with a few hundred stars. Almost all feedback is pretty good. It's not a library though, and I don't distribute binaries, so this instantly weeds out anybody not willing to compile things themselves. That's probably a huge factor. It also only runs on linux. Maybe that's a factor too. Choose your audience.
- franciscop 6y ago
  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 entitlement of some people.
  - noitsnot 6y ago
    I think that's understandable. You closed issues for bugs you didn't resolve.
    - sgillen 6y ago
      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 it’s one person but when it’s 100 it gets overwhelming.
      - stickfigure 6y ago
        Sure. On the other hand, sometimes people put a lot of time and effort into isolating an issue and writing up the best description they can manage. Closing the issue is a one-click FU to the people who are doing their best to help. Some users are overly entitled, but some maintainers are self-absorbed douchebags. I've seen both sides.
        cellularmitosis 6y ago
        I will never understand this point of view. The author has already given you possibly hundreds of hours of free labor simply by publishing the project. But now, because they won’t give you a few more, they’re a douchebag? Even if they close all issues with no comment, they have given you a such _massive_ head start vs having to write the entire project yourself from scratch. How can you be anything but grateful?
- laurentdc 6y ago
  I agree it's an audience problem. I had a Wordpress plugin up and I'd get all sorts of entitled requests, borderline "plz fix my website you broke it". 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.
  - chii 6y ago
    > I'd get all sorts of entitled requests, borderline "plz fix my website you broke it" which will be interesting to see if you ask them for payment for fixes, would they pay?
    - travisjungroth 6y ago
      They’d probably consider it ransomware lol
    - tasogare 6y ago
      That’s exactly what I would do. It’s very similar to people asking you to fix their computer for free when you have tech skills. Ask money (even just 5€) and 90% of requests fade away. The one that remains are willing to pay (and more than a few bucks).
      - Drdrdrq 6y ago
        Are you saying you would solve all my sw problems for 5€? Deal! Let me send you this project I have... :) Be careful.
  - freedomben 6y ago
    At the risk of stereotyping a bit here (from personal experience), Wordpress users tend to be a lot less technical than C programmers, and I find the less technical the audience, the more entitled they tend to be. My theory is that because they don't sling code themselves, they just don't understand how much work and effort goes in to making good software. Because they don't understand it, they tend to not appreciate it.
- a_cool_username 6y ago
  I partially maintain a GitHub project with ~1500 stars, many of my users are not very technically skilled. I rarely encounter entitled/mean/crazy people - we probably average one obnoxious contributor a year, two or three if you count the ones who go away when you politely tell them it's not going to happen. I get a lot of PRs and reasonably well-written issues from users whose profiles indicate it's their first contribution. 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.
  - franciscop 6y ago
    Totally agree. I have 100+ repositories open sourced (Just launched this website yesterday! https://statux.dev/ https://statux.dev/), a handful of them with 1k+ stars, and for the most part it's just me maintaining those. 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.
- maple3142 6y ago
  Same experience. I have a project that can be used by non programmers, and it also gained some popularity in some community. So, I often found people who don't know how to set it up by following the README opening issues ask how to do that. What's more, they don't even bother to search issues before creating a new issue.
- deleted 6y ago
  [deleted]
- wpietri 6y ago
  Yeah, I feel that for sure. I MITMed my robot vacuum and wrote a little python library for it. I assumed that it would, like my other open source code, get approximately no attention. Even at a couple hundred stars, it became a notable pain in the ass. When that vacuum died, freeing me from any sense of responsibility for the code, it was a sweet day indeed.
  - giantDinosaur 6y ago
    Oddly cute story. :)
- daenz 6y ago
  Author of a project with > 5k stars here[0]. I honestly haven't had any experience with mean people for the nearly 10 years since I started it. I've had maybe one or two pushy people, but it was mostly justified (I hadn't pushed a release in like 3 years). They were pushing me to find a maintainer if I wasn't going to answer some of the open requests. 0. https://github.com/amoffat/sh https://github.com/amoffat/sh
- digianarchist 6y ago
  Have you ever wandered into the issues section on Github for say a jQuery slider library or Wordpress plugin? Oh boy you'd have thought people had paid thousands of dollars for the code the way people talk to the maintainers.
- jondubois 6y ago
  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/ 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.
- cxr 6y ago
  It's simple. On the whole, GitHub just kind of sucks. 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.
dnautics 6y ago
As the author of shitty open source libraries I agree, but a bit of a disclaimer in the readme should be expected.
- koheripbal 6y ago
  Should I remove all the "TODO:" lines first?
  - jimsmart 6y ago
    I don't in any of my open projects. They're there for a reason! 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'.
  - grayclhn 6y ago
    No — they’re useful for you (presumably) which is enough reason to keep them. But they’re useful documentation too. I’ll usually search for “todo” as part of evaluating a library because it highlights what’s missing as well as the developer’s priorities and mindset.
- blihp 6y ago
  Unless you have something specific to point out / warn users about, why? It is what it is, and unless users contribute something back to make it better, it's cost them nothing. If they did contribute something back, then hopefully it's a little less shitty. Unless the library in question is objectively bad and/or non-functional, no apologies or disclaimers are necessary.
  - jacoblambda 6y ago
    I see nothing wrong with a disclaimer along the lines of "This is a hobby project. As the author I care about this project and want it to be as good as possible but don't expect the kind of polish you'd see in projects with corporate backings." It doesn't discredit the project in any capacity, it just tempers users expectations.
conroy 6y ago
I maintain an open source project with ~2k stars (https://github.com/kyleconroy/sqlc https://github.com/kyleconroy/sqlc). There’s a large list of bug reports and feature requests, but since I don’t work on it full time, I’ve gotten really good at saying “No” and “I’m sorry”.
- tomkwong 6y ago
  You can probably leave the sorry part out. There’s nothing to be sorry about :-)
  - random32840 6y ago
    Text is ambiguous, overtly communicating that you aren't trying to be mean is a good idea IMO.
- CameronNemo 6y ago
  Your project is somewhat similar to sqlboiler, but not quite the same. You may want to link to it as a complement or alternative when you think it would do a better job of what someone is asking for.
- beart 6y ago
  Is there anything preventing you from adding other maintainers to the project?
saurik 6y ago
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 (though I do know--all too well, as the sole maintainer of some key projects for a sometimes ungrateful ecosystem--that there are many people who really are just looking to be assholes), it is more often that you overhyped a side project and then put it somewhere obvious for other people to find it, only for them to discover that it was "a bit shitty" long after they deployed it; and 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? When you release code that you don't intend to back up with a ton of time and resources, please do the rest of us a favor and use a name that no one is going to mistake for a standard package, put a note on it that says "this is a side project" so expectations are clear, don't write a readme file in the past tense about features you hope to one day implement, or, if you just can't bring yourself to be responsible like this, maybe just reconsider whether you need to publish it at all, as it actually doesn't necessarily make the world a better place just because it is open source. Seriously: 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 even though "it is ok for you to not really know how to cook or not have that much time and participate in the potluck anyway".
- nexuist 6y ago
  > 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 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.
andrewstuart 6y ago
But when potential employers come looking at your work they'll say "hey this code is shitty! It's not a work of art with 100% code coverage tests and perfect in every way. We can't possibly give you a job. Every line of code in our corporate repo is Mona Lisa quality, we can't let rubbishy developers like you in."
- ashtonkem 6y ago
  As a hiring manager, I have never done that.
  - andrewstuart 6y ago
    Do you ask to look at their github? If yes, then what's the point if you're not trying to see the quality of the code and the tests?
    - munchbunny 6y ago
      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 coding from GitHub alone. Most of my own public contributions are cases of “four days studying, two hours coding.” So as an exercise in tempering my interviewer ego, I remind myself that by just looking their work, I am very likely missing a lot of the picture.
      - andrewstuart 6y ago
        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 coming out of the assessment "process".
mceachen 6y ago
As 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.
- judge2020 6y ago
  I find the GitHub "archive repo" functionality a great, easy way to indicate a repo is abandoned; the most you need/have to do is a little readme edit/repo description edit if you want to explain or point to a good alternative.
  - andrewstuart 6y ago
    Problem is there's no auto detection that a repo is no longer maintained. Easy to do but github does not do it.
    - pabs3 6y ago
      "No longer maintained" is hard to define, does no commits in the last year mean "this project is mature and needs no changes", "this project is dead and should not be used" or "the author still cares about this project but is busy with other stuff this year" or something else?
      - deleted 6y ago
        [deleted]
      - CameronNemo 6y ago
        Exactly. It is subjective. One just needs to look at the contribution history and determine if it is what they need.
    - grogenaut 6y ago
      The first thing I do is just check commit history for recent commits. Usually a good indicator a thing is abandoned
quercus 6y ago
I used to maintain a bunch of open source libs but stopped because I felt the expectations from users were unrealistic for something that was not my full time job. Open source is great but I wouldn't do it again unless maintenance was my top focus.
tych0 6y ago
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.
- j88439h84 6y ago
  Been using it for years, I really appreciate your work!
  - tych0 6y ago
    Hey cool, thanks :)
- mikelward 6y ago
  qtile? I don't get the joke. It seems legit to me! Thanks for your time!
- dmpayton 6y ago
  Some of my favorite memories of open source involvement have been contributing to that "shitty" project. Thanks for helping to keep it going!
  - tych0 6y ago
    Yeah! Thank you too. The excellent web pages and docs would not be there without your efforts.
bredren 6y ago
I just picked up maintainership of django-address. It is a set of models and methods for dealing with postal addresses in Django. 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.
- imgabe 6y ago
  Glad to hear someone is picking up maintenance for this! I found it via Google a while ago and ended up forking it to make it play more nicely with Google Maps. I really appreciated the starting point though and that a lot of the heavy lifting of creating a custom model field had been done.
  - bredren 6y ago
    Right on. Please reply in the 'path forward' issue with a link to your fork. I'm interested in learning how people have taken upon themselves to improve the package.
pfdietz 6y ago
If you find an open source library that could be better, and you are using it, make it better yourself.
- random32840 6y ago
  This is naive. If it's a bad library full of bugs, it's going to be garbage code. I'm not going to spend inordinate amounts of time & effort wrestling with shitty code to earn the right to say the library is bad. IMO that's not a good standard.
  - pfdietz 6y ago
    I wasn't saying you couldn't call it bad. But I will say demanding it not be bad would be stepping over a line. 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.
    - random32840 6y ago
      You're right, I misread. I apologise.
duxup 6y ago
Even outside of open source one of the things I always have to get over is ... writing bad code is ok. 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...
underdeserver 6y ago
Missing (2015), though the message is timeless.
- dang 6y ago
  Added. Thanks!
Gother01 6y ago
definitely no it's not, by no mean if it is shitty don't even bother uploading it to github. there is already enough and more than enough amount of this type of projects.
galonk 6y ago
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 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.
- speedgoose 6y ago
  Why would your employer decide what you do on your spare time?
  - cyphar 6y ago
    Not everyone wants to (or is able to) to work on projects in their spare time.
    - speedgoose 6y ago
      Oh yes I didn't read well, my bad.
  - saagarjha 6y ago
    Because unfortunately the law permits them to do this in many cases so they take advantage of this ability.
- fendy3002 6y ago
  Have you put some disclaimer about your situation and said that this repo won't be maintained and feel free to fork? I think it'll be the best resolution for your situation.
  - galonk 6y ago
Justsignedup 6y ago
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 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.
- pjmlp 6y ago
  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.
- yuribro 6y ago
  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...
  - qu83rt 6y ago
    Different people have wildly different ideas about what the point of open source is.
  - mattlondon 6y ago
    People often act very entitled about open source I've found. 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.
deleted 6y ago
[deleted]
glangdale 6y ago
I've initiated 2 OSS libraries that are major libraries in their fields (hyperscan and simdjson), although neither were things that I have done the majority - or even all that much - day-to-day coding on. I totally agree with the 'bit shitty' aspect. 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.
harikb 6y ago
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.
- dgellow 6y ago
  Yes, that would be really useful. Currently looking evaluating forks can be really a pain.
- Pawamoy 6y ago
  Why not checking the contributors instead of the forks? Just pick the most regular ones, or the ones that contributed the most (in number of PRs).
- cellularmitosis 6y ago
  At scale, how do you tell the difference between software which is finished vs software which is unmaintained?
  - chadlavi 6y ago
    "Finished software" is a myth.
    - cellularmitosis 6y ago
      Though I love a good fatalistic Jamie Zawinski reference, I’ll resist and stay on-topic. I think you mean “for the kind of software I typically get paid to write, software is never finished.” However, if you widen your perspective a bit, you’ll find plenty of examples. I assure you, “space invaders” was finished in 1978, and it will never see any “maintenance”.
nanoscopic 6y ago
I agree with this to the extent that "open source your library" means "publish it on Github". Adding it into a package management system, be it one for a language or one for a Linux distro, is implying some level of stability and functionality. This is especially true if you choose a desirable namespace for your project on a system that doesn't differentiate by username. 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.
- ProZsolt 6y ago
  If you want to others use it, then document it. I really appreciate it. Otherwise, if you only wrote it for yourself you did enough. Undocumented code is better than no code. If you didn't publish at all I would have to start from zero.
johndoe42377 6y ago
So, we like to have some clickbait on the front row? Ok. I have a few more. 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.
posedge 6y ago
Thanks so much for saying this. Those thoughts hold me back when I'm thinking about starting an open source project. I already do lots of coding at work. I'm single and no kids, but spending a large amount of time on it in my free time would totally wreck my balance. I love coding but I also need non-technical activities in my life.
jokoon 6y ago
A fair answer: "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"
Jaruzel 6y ago
The nice thing about your shitty code is that it's yours and you don't have to open source it if you don't want to. 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.
leibnitz27 6y ago
I have an OSS 'fun project' - I'm still amazed by the number of issues/emails I get raised which say: "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.
- pydry 6y ago
  I see similar types of reactions to intra-team pull request comments. I think it's a facet of the facelessness of online comments. 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.
- rmetzler 6y ago
  Thanks for acknowledging this might be a language or cultural thing. I’m sure this kind of „smalltalk“ is appreciated when you put your free time into what others maybe use for their job. 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.
rikroots 6y ago
From the article: > 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!
- tenaciousDaniel 6y ago
  what's the side project?
  - rikroots 6y ago
    https://github.com/KaliedaRik/Scrawl-canvas https://github.com/KaliedaRik/Scrawl-canvas
samblr 6y ago
Github should seriously think of making amount of time spent by developers behind a repository. Even a rough heuristic will do. 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.
altitudinous 6y ago
Yes, it is OK. Any software is allowed to be shitty as long as it works. But then people always go out of their way to tell you how shitty it is. The type of immature dev people who hang about here on Hacker News TBH. I ignore the mails, the terrible opinions because there are people who love what I do, although underneath it is not perfect.
ExtremisAndy 6y ago
I have never contributed to open source because I have always been so impressed with the source code I’ve seen in these projects. It intimidates me! I’m a self-taught programmer, and while I’ve certainly written thousands of lines of useful code (useful to me, in any case), I know it isn’t “correct” (as in, idiomatic or ideally what you should write). If I could ever get to the place where I trusted my own work, I’d love to contribute to open source because I do have a few projects in mind (mainly useful to folks in the humanities) that I know I can make, but I’m just too embarrassed at the low quality/ugliness of my code.
- pantalaimon 6y ago
  > I know it isn’t “correct” (as in, idiomatic or ideally what you should write). 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. :)
- gus_massa 6y ago
  Start fixing typos in the docs and error messages in projects you use. 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.)
- gitgud 6y ago
  > but I’m just too embarrassed at the low quality/ugliness of my code. 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...
rlayton2 6y ago
Just a FYI for the library authors out there, but you can usually set a template for submitting bug reports and issues (for instance, Github has this feature). This can help put a message in front of users right as they are making the issue. It might not fully alleviate the issue, but it might help set expectations! (i.e. "Please feel free to submit a bug report, but please note we are volunteers. We cannot get to every issue, and we can more easily resolve issues that are well researched before making it here.")
deleted 6y ago
[deleted]
nayuki 6y ago
Daniel Compton: Open Source Is Free As in Baby: https://danielcompton.net/2014/11/19/dependencies https://danielcompton.net/2014/11/19/dependencies > 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.
deleted 6y ago
[deleted]
1-KB-OK 6y ago
A dilemma that we are running into at work is that we have all our software open source and readily available on github but use an internal bug tracker to manage bugs picked up by QE and other people in our org. These bugs are given significantly higher priority than our GH issues and we end up with a pile of GH issues that no one has the time or ability to adequately track. As our team recently set up its own open source working group and generally is making open source contributions in other projects a higher priority I see this problem getting worse. Does anyone have any suggestions how to overcome such an issue? 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.
Quanttek 6y ago
The author posted a follow-up piece: https://www.drmaciver.com/2015/04/surprise-feminism/ https://www.drmaciver.com/2015/04/surprise-feminism/
Upvoter33 6y ago
Not everything worth doing is worth doing well -Tom West
LockAndLol 6y ago
Reminds me of that rust developer who wrote a super-fast webserver... and was trashed by the rust community for not upholding their standards. When he finally had enough and said he was going to (IIRC) delete the project, suddenly people started being nice. People never fail to impress me negatively.
nonbirithm 6y ago
It's a matter of expectations. I believe expectations are extremely important when releasing anything creative, be it code or art or writing. 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 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.
coronadisaster 6y ago
It is not ok if you want open source to take over the world.

650 points by mmcloughlin 6y ago

I've a little anecdote on this. Once at a community potluck, our table ended up with several wine bottles...but no corkscrew. I reasonably asked a neighboring table to borrow one of their own (nice ppl, but strangers). Well, nicely, they lent me some suspiciously plasticky version of a corkscrew, literally, the screw was made of some sort of plastic!). Shitty, in one word... Sure enough it snapped, the cork still stuck, I'm embarassed, offered the owner another wine bottle in apology. Had a laugh about it together and fun time. But it was a lesson on shittiness-in-disguise-of-utility. 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.

nerdbaggy 6y ago

I 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.

WrtCdEvrydy 6y ago
Honestly, always give them the "We'll review your PR once it's ready".
sergiotapia 6y ago
I have a pretty simple project with 2.4k stars, and have met nothing but good people eager to help, and bending over backwards to help me help them. My project's "niche" may have something to do with it.
- hazz99 6y ago
  What is it / what niche?
  - deleted 6y ago
    [deleted]
  - sergiotapia 6y ago
    https://github.com/sergiotapia/magnetissimo https://github.com/sergiotapia/magnetissimo - niche is: "self-hosted apps"
- marcandre 6y ago
  Application domain may have something to do with it, language also. As a maintainer of Javascript and Ruby libraries, the difference in entitlement and cluelessness is remarkable.
  - tonyedgecombe 6y ago
    The Ruby community has always struck me as friendly and welcoming.
- klenwell 6y ago
  This is encouraging to hear. My company built a tool to improve website accessibility. It fills a niche. We're almost ready to open source it. Basically just need to make the Github repo public. 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.
kick 6y ago
You can just...ignore people, on the Internet. It's a really useful thing! Once you accept that not all requests/insults/questions/comments are equal, and some are drastically less valuable than others, it becomes pretty easy. The initial mental barrier you have to break to do so is hard to get around, though.
gitgud 6y ago
In my experience, it depends what the project is and who is attracted to the github issues. 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.
smcameron 6y ago
I have a github project with a few hundred stars. Almost all feedback is pretty good. It's not a library though, and I don't distribute binaries, so this instantly weeds out anybody not willing to compile things themselves. That's probably a huge factor. It also only runs on linux. Maybe that's a factor too. Choose your audience.
franciscop 6y ago
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 entitlement of some people.
- noitsnot 6y ago
  I think that's understandable. You closed issues for bugs you didn't resolve.
  - sgillen 6y ago
    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 it’s one person but when it’s 100 it gets overwhelming.
    - stickfigure 6y ago
      Sure. On the other hand, sometimes people put a lot of time and effort into isolating an issue and writing up the best description they can manage. Closing the issue is a one-click FU to the people who are doing their best to help. Some users are overly entitled, but some maintainers are self-absorbed douchebags. I've seen both sides.
      - cellularmitosis 6y ago
        I will never understand this point of view. The author has already given you possibly hundreds of hours of free labor simply by publishing the project. But now, because they won’t give you a few more, they’re a douchebag? Even if they close all issues with no comment, they have given you a such _massive_ head start vs having to write the entire project yourself from scratch. How can you be anything but grateful?
laurentdc 6y ago
I agree it's an audience problem. I had a Wordpress plugin up and I'd get all sorts of entitled requests, borderline "plz fix my website you broke it". 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.
- chii 6y ago
  > I'd get all sorts of entitled requests, borderline "plz fix my website you broke it" which will be interesting to see if you ask them for payment for fixes, would they pay?
  - travisjungroth 6y ago
    They’d probably consider it ransomware lol
  - tasogare 6y ago
    That’s exactly what I would do. It’s very similar to people asking you to fix their computer for free when you have tech skills. Ask money (even just 5€) and 90% of requests fade away. The one that remains are willing to pay (and more than a few bucks).
    - Drdrdrq 6y ago
      Are you saying you would solve all my sw problems for 5€? Deal! Let me send you this project I have... :) Be careful.
- freedomben 6y ago
  At the risk of stereotyping a bit here (from personal experience), Wordpress users tend to be a lot less technical than C programmers, and I find the less technical the audience, the more entitled they tend to be. My theory is that because they don't sling code themselves, they just don't understand how much work and effort goes in to making good software. Because they don't understand it, they tend to not appreciate it.
a_cool_username 6y ago
I partially maintain a GitHub project with ~1500 stars, many of my users are not very technically skilled. I rarely encounter entitled/mean/crazy people - we probably average one obnoxious contributor a year, two or three if you count the ones who go away when you politely tell them it's not going to happen. I get a lot of PRs and reasonably well-written issues from users whose profiles indicate it's their first contribution. 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.
- franciscop 6y ago
  Totally agree. I have 100+ repositories open sourced (Just launched this website yesterday! https://statux.dev/ https://statux.dev/), a handful of them with 1k+ stars, and for the most part it's just me maintaining those. 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.
maple3142 6y ago
Same experience. I have a project that can be used by non programmers, and it also gained some popularity in some community. So, I often found people who don't know how to set it up by following the README opening issues ask how to do that. What's more, they don't even bother to search issues before creating a new issue.
deleted 6y ago
[deleted]
wpietri 6y ago
Yeah, I feel that for sure. I MITMed my robot vacuum and wrote a little python library for it. I assumed that it would, like my other open source code, get approximately no attention. Even at a couple hundred stars, it became a notable pain in the ass. When that vacuum died, freeing me from any sense of responsibility for the code, it was a sweet day indeed.
- giantDinosaur 6y ago
  Oddly cute story. :)
daenz 6y ago
Author of a project with > 5k stars here[0]. I honestly haven't had any experience with mean people for the nearly 10 years since I started it. I've had maybe one or two pushy people, but it was mostly justified (I hadn't pushed a release in like 3 years). They were pushing me to find a maintainer if I wasn't going to answer some of the open requests. 0. https://github.com/amoffat/sh https://github.com/amoffat/sh
digianarchist 6y ago
Have you ever wandered into the issues section on Github for say a jQuery slider library or Wordpress plugin? Oh boy you'd have thought people had paid thousands of dollars for the code the way people talk to the maintainers.
jondubois 6y ago
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/ 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.
cxr 6y ago
It's simple. On the whole, GitHub just kind of sucks. 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.

dnautics 6y ago

As the author of shitty open source libraries I agree, but a bit of a disclaimer in the readme should be expected.

koheripbal 6y ago
Should I remove all the "TODO:" lines first?
- jimsmart 6y ago
  I don't in any of my open projects. They're there for a reason! 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'.
- grayclhn 6y ago
  No — they’re useful for you (presumably) which is enough reason to keep them. But they’re useful documentation too. I’ll usually search for “todo” as part of evaluating a library because it highlights what’s missing as well as the developer’s priorities and mindset.
blihp 6y ago
Unless you have something specific to point out / warn users about, why? It is what it is, and unless users contribute something back to make it better, it's cost them nothing. If they did contribute something back, then hopefully it's a little less shitty. Unless the library in question is objectively bad and/or non-functional, no apologies or disclaimers are necessary.
- jacoblambda 6y ago
  I see nothing wrong with a disclaimer along the lines of "This is a hobby project. As the author I care about this project and want it to be as good as possible but don't expect the kind of polish you'd see in projects with corporate backings." It doesn't discredit the project in any capacity, it just tempers users expectations.

conroy 6y ago

I maintain an open source project with ~2k stars (https://github.com/kyleconroy/sqlc https://github.com/kyleconroy/sqlc). There’s a large list of bug reports and feature requests, but since I don’t work on it full time, I’ve gotten really good at saying “No” and “I’m sorry”.

tomkwong 6y ago
You can probably leave the sorry part out. There’s nothing to be sorry about :-)
- random32840 6y ago
  Text is ambiguous, overtly communicating that you aren't trying to be mean is a good idea IMO.
CameronNemo 6y ago
Your project is somewhat similar to sqlboiler, but not quite the same. You may want to link to it as a complement or alternative when you think it would do a better job of what someone is asking for.
beart 6y ago
Is there anything preventing you from adding other maintainers to the project?

saurik 6y ago

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 (though I do know--all too well, as the sole maintainer of some key projects for a sometimes ungrateful ecosystem--that there are many people who really are just looking to be assholes), it is more often that you overhyped a side project and then put it somewhere obvious for other people to find it, only for them to discover that it was "a bit shitty" long after they deployed it; and 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? When you release code that you don't intend to back up with a ton of time and resources, please do the rest of us a favor and use a name that no one is going to mistake for a standard package, put a note on it that says "this is a side project" so expectations are clear, don't write a readme file in the past tense about features you hope to one day implement, or, if you just can't bring yourself to be responsible like this, maybe just reconsider whether you need to publish it at all, as it actually doesn't necessarily make the world a better place just because it is open source. Seriously: 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 even though "it is ok for you to not really know how to cook or not have that much time and participate in the potluck anyway".

nexuist 6y ago
> 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 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.

andrewstuart 6y ago

But when potential employers come looking at your work they'll say "hey this code is shitty! It's not a work of art with 100% code coverage tests and perfect in every way. We can't possibly give you a job. Every line of code in our corporate repo is Mona Lisa quality, we can't let rubbishy developers like you in."

ashtonkem 6y ago
As a hiring manager, I have never done that.
- andrewstuart 6y ago
  Do you ask to look at their github? If yes, then what's the point if you're not trying to see the quality of the code and the tests?
  - munchbunny 6y ago
    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 coding from GitHub alone. Most of my own public contributions are cases of “four days studying, two hours coding.” So as an exercise in tempering my interviewer ego, I remind myself that by just looking their work, I am very likely missing a lot of the picture.
    - andrewstuart 6y ago
      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 coming out of the assessment "process".

mceachen 6y ago

As 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.

judge2020 6y ago
I find the GitHub "archive repo" functionality a great, easy way to indicate a repo is abandoned; the most you need/have to do is a little readme edit/repo description edit if you want to explain or point to a good alternative.
- andrewstuart 6y ago
  Problem is there's no auto detection that a repo is no longer maintained. Easy to do but github does not do it.
  - pabs3 6y ago
    "No longer maintained" is hard to define, does no commits in the last year mean "this project is mature and needs no changes", "this project is dead and should not be used" or "the author still cares about this project but is busy with other stuff this year" or something else?
    - deleted 6y ago
      [deleted]
    - CameronNemo 6y ago
      Exactly. It is subjective. One just needs to look at the contribution history and determine if it is what they need.
  - grogenaut 6y ago
    The first thing I do is just check commit history for recent commits. Usually a good indicator a thing is abandoned

quercus 6y ago

I used to maintain a bunch of open source libs but stopped because I felt the expectations from users were unrealistic for something that was not my full time job. Open source is great but I wouldn't do it again unless maintenance was my top focus.

tych0 6y ago

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.

j88439h84 6y ago
Been using it for years, I really appreciate your work!
- tych0 6y ago
  Hey cool, thanks :)
mikelward 6y ago
qtile? I don't get the joke. It seems legit to me! Thanks for your time!
dmpayton 6y ago
Some of my favorite memories of open source involvement have been contributing to that "shitty" project. Thanks for helping to keep it going!
- tych0 6y ago
  Yeah! Thank you too. The excellent web pages and docs would not be there without your efforts.

bredren 6y ago

I just picked up maintainership of django-address. It is a set of models and methods for dealing with postal addresses in Django. 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.

imgabe 6y ago
Glad to hear someone is picking up maintenance for this! I found it via Google a while ago and ended up forking it to make it play more nicely with Google Maps. I really appreciated the starting point though and that a lot of the heavy lifting of creating a custom model field had been done.
- bredren 6y ago
  Right on. Please reply in the 'path forward' issue with a link to your fork. I'm interested in learning how people have taken upon themselves to improve the package.

pfdietz 6y ago

If you find an open source library that could be better, and you are using it, make it better yourself.

random32840 6y ago
This is naive. If it's a bad library full of bugs, it's going to be garbage code. I'm not going to spend inordinate amounts of time & effort wrestling with shitty code to earn the right to say the library is bad. IMO that's not a good standard.
- pfdietz 6y ago
  I wasn't saying you couldn't call it bad. But I will say demanding it not be bad would be stepping over a line. 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.
  - random32840 6y ago
    You're right, I misread. I apologise.

duxup 6y ago

Even outside of open source one of the things I always have to get over is ... writing bad code is ok. 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...

underdeserver 6y ago

Missing (2015), though the message is timeless.

dang 6y ago
Added. Thanks!

Gother01 6y ago

definitely no it's not, by no mean if it is shitty don't even bother uploading it to github. there is already enough and more than enough amount of this type of projects.

galonk 6y ago

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 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.

speedgoose 6y ago
Why would your employer decide what you do on your spare time?
- cyphar 6y ago
  Not everyone wants to (or is able to) to work on projects in their spare time.
  - speedgoose 6y ago
    Oh yes I didn't read well, my bad.
- saagarjha 6y ago
  Because unfortunately the law permits them to do this in many cases so they take advantage of this ability.
fendy3002 6y ago
Have you put some disclaimer about your situation and said that this repo won't be maintained and feel free to fork? I think it'll be the best resolution for your situation.
- galonk 6y ago

Justsignedup 6y ago

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 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.

pjmlp 6y ago
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.
yuribro 6y ago
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...
- qu83rt 6y ago
  Different people have wildly different ideas about what the point of open source is.
- mattlondon 6y ago
  People often act very entitled about open source I've found. 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.

deleted 6y ago

[deleted]

glangdale 6y ago

I've initiated 2 OSS libraries that are major libraries in their fields (hyperscan and simdjson), although neither were things that I have done the majority - or even all that much - day-to-day coding on. I totally agree with the 'bit shitty' aspect. 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.

harikb 6y ago

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.

dgellow 6y ago
Yes, that would be really useful. Currently looking evaluating forks can be really a pain.
Pawamoy 6y ago
Why not checking the contributors instead of the forks? Just pick the most regular ones, or the ones that contributed the most (in number of PRs).
cellularmitosis 6y ago
At scale, how do you tell the difference between software which is finished vs software which is unmaintained?
- chadlavi 6y ago
  "Finished software" is a myth.
  - cellularmitosis 6y ago
    Though I love a good fatalistic Jamie Zawinski reference, I’ll resist and stay on-topic. I think you mean “for the kind of software I typically get paid to write, software is never finished.” However, if you widen your perspective a bit, you’ll find plenty of examples. I assure you, “space invaders” was finished in 1978, and it will never see any “maintenance”.

nanoscopic 6y ago

I agree with this to the extent that "open source your library" means "publish it on Github". Adding it into a package management system, be it one for a language or one for a Linux distro, is implying some level of stability and functionality. This is especially true if you choose a desirable namespace for your project on a system that doesn't differentiate by username. 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.

ProZsolt 6y ago
If you want to others use it, then document it. I really appreciate it. Otherwise, if you only wrote it for yourself you did enough. Undocumented code is better than no code. If you didn't publish at all I would have to start from zero.

johndoe42377 6y ago

So, we like to have some clickbait on the front row? Ok. I have a few more. 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.

posedge 6y ago

Thanks so much for saying this. Those thoughts hold me back when I'm thinking about starting an open source project. I already do lots of coding at work. I'm single and no kids, but spending a large amount of time on it in my free time would totally wreck my balance. I love coding but I also need non-technical activities in my life.

jokoon 6y ago

A fair answer: "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"

Jaruzel 6y ago

The nice thing about your shitty code is that it's yours and you don't have to open source it if you don't want to. 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.

leibnitz27 6y ago

I have an OSS 'fun project' - I'm still amazed by the number of issues/emails I get raised which say: "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.

pydry 6y ago
I see similar types of reactions to intra-team pull request comments. I think it's a facet of the facelessness of online comments. 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.
rmetzler 6y ago
Thanks for acknowledging this might be a language or cultural thing. I’m sure this kind of „smalltalk“ is appreciated when you put your free time into what others maybe use for their job. 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.

rikroots 6y ago

From the article: > 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!

tenaciousDaniel 6y ago
what's the side project?
- rikroots 6y ago
  https://github.com/KaliedaRik/Scrawl-canvas https://github.com/KaliedaRik/Scrawl-canvas

samblr 6y ago

Github should seriously think of making amount of time spent by developers behind a repository. Even a rough heuristic will do. 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.

altitudinous 6y ago

Yes, it is OK. Any software is allowed to be shitty as long as it works. But then people always go out of their way to tell you how shitty it is. The type of immature dev people who hang about here on Hacker News TBH. I ignore the mails, the terrible opinions because there are people who love what I do, although underneath it is not perfect.

ExtremisAndy 6y ago

I have never contributed to open source because I have always been so impressed with the source code I’ve seen in these projects. It intimidates me! I’m a self-taught programmer, and while I’ve certainly written thousands of lines of useful code (useful to me, in any case), I know it isn’t “correct” (as in, idiomatic or ideally what you should write). If I could ever get to the place where I trusted my own work, I’d love to contribute to open source because I do have a few projects in mind (mainly useful to folks in the humanities) that I know I can make, but I’m just too embarrassed at the low quality/ugliness of my code.

pantalaimon 6y ago
> I know it isn’t “correct” (as in, idiomatic or ideally what you should write). 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. :)
gus_massa 6y ago
Start fixing typos in the docs and error messages in projects you use. 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.)
gitgud 6y ago
> but I’m just too embarrassed at the low quality/ugliness of my code. 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...

rlayton2 6y ago

Just a FYI for the library authors out there, but you can usually set a template for submitting bug reports and issues (for instance, Github has this feature). This can help put a message in front of users right as they are making the issue. It might not fully alleviate the issue, but it might help set expectations! (i.e. "Please feel free to submit a bug report, but please note we are volunteers. We cannot get to every issue, and we can more easily resolve issues that are well researched before making it here.")

deleted 6y ago

[deleted]

nayuki 6y ago

Daniel Compton: Open Source Is Free As in Baby: https://danielcompton.net/2014/11/19/dependencies https://danielcompton.net/2014/11/19/dependencies > 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.

deleted 6y ago

[deleted]

1-KB-OK 6y ago

A dilemma that we are running into at work is that we have all our software open source and readily available on github but use an internal bug tracker to manage bugs picked up by QE and other people in our org. These bugs are given significantly higher priority than our GH issues and we end up with a pile of GH issues that no one has the time or ability to adequately track. As our team recently set up its own open source working group and generally is making open source contributions in other projects a higher priority I see this problem getting worse. Does anyone have any suggestions how to overcome such an issue? 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.

Quanttek 6y ago

The author posted a follow-up piece: https://www.drmaciver.com/2015/04/surprise-feminism/ https://www.drmaciver.com/2015/04/surprise-feminism/

Upvoter33 6y ago

Not everything worth doing is worth doing well -Tom West

LockAndLol 6y ago

Reminds me of that rust developer who wrote a super-fast webserver... and was trashed by the rust community for not upholding their standards. When he finally had enough and said he was going to (IIRC) delete the project, suddenly people started being nice. People never fail to impress me negatively.

nonbirithm 6y ago

It's a matter of expectations. I believe expectations are extremely important when releasing anything creative, be it code or art or writing. 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 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.

coronadisaster 6y ago

It is not ok if you want open source to take over the world.