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.
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".
"sure: it is totally their fault for deploying something without carefully reading your code to figure out that it was a bit shitty beforehand"
Yes you must read and understand everything or have trust in the publisher. Relying on the package name is going to get you in trouble. Sounds like a great exploit opportunity.
> 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.
> 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:
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?
Agreed. People who demand free labor from open-source maintainers get a lot of deserved flak lately, but it is not that project authors are always blameless. Everyone who publishes some code for others to use faces a dilemma: they want their project to be popular (because being associated with a popular project is prestigious), but popularity means that the project demands additional effort to polish it, deal with bug reports and pull requests etc. So there is a temptation to convey the appearance of maturity without putting in the required effort.
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.
I agree with readme needs to specifically mention unimplemented features. But the responsibility for using an unpopular library lies fully on the user, not author. Of course if the library is popular, author needs to maintain it, or delegate auhority to other maintainers.
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.
> it also can simultaneously be not OK for you to publish it in a package directory with a generic name and a description
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 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 way I look at it is that releasing an open-source library is like bringing a child into this world: its utmost well-being is your responsibility. If you don't have the bandwidth for that, don't publish it. And, if your circumstances change later, find another maintainer -- after all, you wouldn't just abandon your child on the street, would you?
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.
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.
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.
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.
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.
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.
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.
I was surprised to hear that many open source developers get so many 'mean and entitled people' complaining on their project channels. My project https://socketcluster.io/ has almost 6K stars on GitHub and all I only ever get are people praising it - Sometimes I worry that people may even be over-praising it and self-censoring criticism (maybe they just like me as a maintainer). I think in its 7 year history, I only remember 1 or 2 complaints out of a total of several hundreds or maybe thousands of feedback comments, messages or emails. I do appreciate criticism though and those few critiques have been valuable.
I think maybe it has to do with:
1. Hype.
2. What percentage of developers were forced to use your tool/library against their will by their employers or forced upon them as a dependency of some other tool.
If a project is overhyped, then developers will be disappointed by reality and they will complain. The best you can do is try to set realistic expectations.
If a developer was forced to use your library by their employer (or it was forced upon them as a dependency of another tool/library that they're using and your dependency was throwing some weird error) then they will also complain. The best you can do about that is try to make your library work 'out of the box' as well as possible and make it work well in as many environments and operating systems as possible. Regulating hype by setting realistic expectations can also help prevent employers from forcing their developers to use a library. You should use more technical terminology instead of business buzz words when describing your project. You want to attract developers, not project managers.
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.
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.
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.
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.
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.
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.
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.
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.
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."
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.
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.
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.
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.
I maintain an open source project with ~2k stars (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”.
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.
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.
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.
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.")
[+] [-] Justsignedup|5 years ago|reply
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.
[+] [-] saurik|5 years ago|reply
[+] [-] wolco|5 years ago|reply
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.
[+] [-] nexuist|5 years ago|reply
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.
[+] [-] Matthias247|5 years ago|reply
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.
[+] [-] asadjb|5 years ago|reply
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?
[+] [-] dunkelheit|5 years ago|reply
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.
[+] [-] fendy3002|5 years ago|reply
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.
[+] [-] DangitBobby|5 years ago|reply
[+] [-] matheusmoreira|5 years ago|reply
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.
[+] [-] bigiain|5 years ago|reply
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...")
[+] [-] fudged71|5 years ago|reply
[+] [-] mozilianulb|5 years ago|reply
[+] [-] m463|5 years ago|reply
[+] [-] enraged_camel|5 years ago|reply
[+] [-] tych0|5 years ago|reply
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.
[+] [-] nerdbaggy|5 years ago|reply
[+] [-] smcameron|5 years ago|reply
[+] [-] franciscop|5 years ago|reply
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.
[+] [-] wpietri|5 years ago|reply
[+] [-] laurentdc|5 years ago|reply
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.
[+] [-] a_cool_username|5 years ago|reply
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.
[+] [-] kick|5 years ago|reply
[+] [-] gitgud|5 years ago|reply
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.
[+] [-] jondubois|5 years ago|reply
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.
[+] [-] digianarchist|5 years ago|reply
Oh boy you'd have thought people had paid thousands of dollars for the code the way people talk to the maintainers.
[+] [-] WrtCdEvrydy|5 years ago|reply
[+] [-] daenz|5 years ago|reply
0. https://github.com/amoffat/sh
[+] [-] sergiotapia|5 years ago|reply
[+] [-] maple3142|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] cxr|5 years ago|reply
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.
[+] [-] nanoscopic|5 years ago|reply
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.
[+] [-] harikb|5 years ago|reply
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.
[+] [-] galonk|5 years ago|reply
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.
[+] [-] leibnitz27|5 years ago|reply
"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.
[+] [-] andrewstuart|5 years ago|reply
[+] [-] dnautics|5 years ago|reply
[+] [-] ExtremisAndy|5 years ago|reply
[+] [-] mceachen|5 years ago|reply
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.
[+] [-] bredren|5 years ago|reply
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.
[+] [-] zoomablemind|5 years ago|reply
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.
[+] [-] quercus|5 years ago|reply
[+] [-] conroy|5 years ago|reply
[+] [-] CameronNemo|5 years ago|reply
[+] [-] beart|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] 1-KB-OK|5 years ago|reply
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.
[+] [-] glangdale|5 years ago|reply
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.
[+] [-] rlayton2|5 years ago|reply