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 know the comment came from a good place and you meant well.
The situation you describe of “developers working on the wrong thing” can and sometimes does happen, however, as a manager the effective way to handle those situations is to address the root cause. Is it because the task is too big, not enough details, is it too early in the project that the requirements haven’t really surfaced organically? You want your team to be autonomous, you want to empower your team to make mistakes and at the same time actively minimize the chance for mistakes by greasing “things” so people around you can be more effective.
There are few things as negative for a team performance as an insecure manager that needs to be making tactical decisions for the team as if developers were little kids.
I agree that a manager shouldn't micromanage to the point that they believe developers cannot be productive without their manager physically present, but that is not what they were talking about. The comment isn't about the developer needing their manager's insight or guidance, but about the developer needing the expertise of the rest of the team, which they will not have access to at nights or on the weekend.
I think in response to the OP, the user identified the "problem." I've worked places where the above was the norm, and other places where if ticket showed up in front of a developer and required additional clarification (from QA or other developers) this would be covered in detail during sprint retrospectives, with the intention of making sure that the team works hard to make sure that this never happens. It can blow estimates not only for the given task, but can have cascading effects as well.
That said, this might not be easily attainable or the best practice for all organizations, but I think I prefer better processes over evening and weekend work.
I for example seem to almost need this kind of rhythm. Yes it is spiky and sometimes a bit chaotic. But also very intrinsically motivated, which can sometimes lead to high impact solutions.
A good way to deal with this tradeoff is writing more text and less code. Text which is off-base is much more valuable than code that does do wrong things or things in a wrong way.
But I have to say that I work alone or in small teams, which requires less technical coordination.
I've seen places where working on your free time and/or weekends would be totally frowned upon by managers, and the general culture around workers would be that working on weekends is giving up your time for free in an attempt to clib on the other's backs, so that wouldn't be very popular among your colleages.
I have no children. I like my job. I spend my free time doing things that aren't software development.
I theoretically could work outside of work hours, sure, if I were a boring person with no interests.
I think that most people who treat their jobs as their 'calling' and burn themselves out on them ruin the world for both themselves and the rest of us. Races to the bottom everywhere.
It doesn't bother me too much though, since ultimately the selection pressure is such that the brown-nosers end up being abused by their managers whilst the stubborn lot get promoted. YMMV.
My American boss regularly feels proud that he puts in 12-14 hour days. In my opinion, that amount of hours makes sense if I am working on my own business or something that truly benefits humanity (like a vaccine for COVID-19 for example). It is hard to do good work more than 6-7 hours per day anyway and much harder to sustain it for long periods of time
If you have a job that's ultimately pointless, then you want to work as little as possible so that you have time for leisure and/or useful work.
Sure, but people with kids win at life.
Let the DINK make some extra money. You still have it better.
That's a pretty insulting statement for those of us who can't have / don't want children.
It's not a competition. We've chosen different paths than you. Not worse, just different.
Kiss of death seemed melodramatic at best though. Every CEO, CTO, and CFO I've worked with had kids. Guess they were the lucky few who didn't have their professional career ruined by those goblin children?
I get under everyone’s skin here. Just seeing my username is enough to get ppl riled up in HN
That entire first line seems entirely unrelated the the words I typed. Did you respond to the correct person?
What’s dumb is to tell people you’re better than Proust because you popped out some brats.
... That was dripping sarcasm. Please don't down vote.
My best friend since childhood has a kid and I can see that he lives an adventure of which he appreciate every second and I enjoy watching him live it. I don't have kids and I live different sorts of adventures and I can see that he lives them vicariously through me. It's pointless to try to make a tally. Figuring out what makes your mind "tick" the most is how you best "win at life".
And then they could either contribute it back, fork your project or just keep it to themselves, if the license allows it. At any rate, you already helped them...
You'll often get angry irate emails/issues raised demanding you help them or add a new feature or whatever. Some people are just clueless and need help, others are just dicks.
It is often not worth the hassle in my opinion, but then everyone's circumstances and motivations are different and I am glad that a lot of people do think it is worth it.
A much better response would be:
1. Scrutinise end users of the code: demand that governments only use this data if proper due dil has been carried out.
2. Submit code improvements.
3. (maybe) Demand that peer reviewers are more rigorous when checking the way results are generated. The issue with this is that this would also be a strong disincentive for scientist to publish their work.
While the tone of the covid model scrutiny leaves a lot to be desired it is understandable seeing as how the results are affecting the entire world. The situation is unprecedented.
My meta point is that people are:
1. pressuring and blaming the wrong party.
2. doings something which will have an unintended strongly negative consequence (make scientists averse to publishing their code).
Yeah, the code's bad – so what? It wasn't written by programmers. Most simulation code is bad, but if it's been proven correct it doesn't need to be good.
From what I can tell, this is a matter of conflicting conventions in different fields meeting head-on.
This is exactly why scientists don't release their code.
In fact, more applications-focused researchers (those who combine real data with established models, for instance) tend to write higher-level scripts stringing more-engineered tools. In this case, open sourcing the scripts would be both easier and more pointless, since they will be almost the same as what is stated in English, tables, and plots in the paper. Epidemiology is usually this way, in my experience, though the linked repository seems to have some of both flavors.
The underlying misunderstand in that issue thread seems to me to be a disagreement on what the main valuable byproducts of scientific programming are. Professionally programmers will naturally think it's the code, but, traditionally, the code has been seen in academia as only a temporary vehicle for the model and it's parameters, which is the real product. (Also, the "program" might really need to include the lab, its papers, and its institutional knowledge, which is harder to package and open-source.)
Right or wrong, the assumption is that any competent grad student could reproduce the result in a week or so of (admittedly unnecessary) greenfield coding. But this is clearly not ideal, and newer work does strive for more professionalism in coding, open-source-by-default, and therefore faster replication. The project in question clearly predates this trend.
(Of course, a third reason academics don't open source is that some secrecy is required before publication in competitive fields. On a months-long project, you might not want to be committing publicly before publication. But this isn't much of an excuse.)
The only thing more frustrating is when I see people swoop into open source code with "security vulns" that are based on nonsense threat models.
Isn't "faith in science" an oxymoron? If anything, people should default to skepticism for hastily thrown together scientific models.
It's interesting. For me there are at least two classes of open source.
1) Project with a single maintainer, or perhaps a small number of key people, nothing in the way of corporate backing, often worked on in spare time, but which can still be very popular and widely used. I always think back to the example of NDoc, which was a great tool for taking raw XML doc comments from .NET code and turning them into beautiful Javadoc-style HTML documentation. It worked incredibly well for .NET 1.x but the .NET 2 support was never finished because the author, Kevin Downs, received abuse and threats via mail-bomb due to it not being ready "fast enough" for some people. Understandable he decided to quit and, as far as I'm aware, not a peep has been heard from him since in terms of OSS contributions. The way Kevin was treated, and the way other OSS maintainers have been treated by both individuals and corporations, is absolutely despicable and completely unacceptable.
2) Corporate backed OSS projects that are actively evangelised: projects like .NET Core, Node, npm, TypeScript, React, Angular. You might even think of something like Firefox in this category since, although Mozilla is a foundation, it's substantially funded by corporate sponsors (mainly Google?), has full time employees paid to work on the products, etc. Some of these might at times have been considered open source in name only: i.e., source code is absolutely available, but there is little or no way for most people outside of the sponsoring organisation to meaningfully contribute. With these I take a slightly different attitude, and I certainly expect sponsoring organisations to take more responsibility for the projects. If you're actively evangelising people to use a project (and especially if you've succeeded in recruiting large numbers of people to use your project), and you're not giving them much opportunity to contribute, then absolutely you need to take responsibility for making sure the project is supported appropriately. That might even include paid support options.
And I suppose perhaps these represent the extremes of a spectrum (perhaps - I don't claim to have this absolutely right, by any means).
Clearly there are a lot of people who would disagree with me on both sides. E.g., people who think every open source project should be like (2) and that all authors bear an equal responsibility for supporting their code. On the flipside, since I've been flamed on this before, I know there are people who think I'm a walking manifestation of all human evil because I've suggested that any open source project might perhaps fall into category (2).
Fundamentally though I think your point stands: a lot of people behave in a way that's very entitled towards individual maintainers of OSS projects. As you say, depending on your circumstances, often not worth the hassle.
Absolutely, but that is often not the expectation. When I have pointed this out in the past people have gotten hysterically angry demonstrating a degree of entitlement. The mere mention they could do it themselves or submit a pull request has been regarded as a hostile personal insult like declaring war or perhaps worse than making sexually profane and racial commentary about their spouse.
1. Allow others to step in as maintainers and review/approve new features and bug fixes in your stead.
or (if you want to maintain control of your library)
2. Be clear that your library is in maintenance mode, and encourage and bless (by linking from your README) a fork (or forks) that work for those who were using your library but want the extra features that you don't want or have time to implement in your library.
Otherwise your project is actively getting in the way of the community organising development of similar.
If you had to go to the trouble of creating your library in the first place, it means either
A) "the community" had not met your specific need, so why would they start now? Or
B) you did this for fun/learning/visibility/coping with a mania, in which case you still don't owe us any favors.
That said, doing either of the above would be nice and appreciated, but you don't have to donate anything above and beyond what you are have.
While you're technically correct that people don't owe anyone anything, I've often had the experience of using an open source library that was otherwise excellent, except that it had critical bugs that hadn't been patched, or that it hadn't been updated to work with the latest versions of it's dependencies. Popular repositories like this often have tens of high-quality pull-requests fixing these issues, but using them is non-trivial because you'd have to merge everything. These PRs pile up for a few months until someone realises that the repo is unmaintained and forks. At which point you have two versions of the project (often with the same name), and everyone is left to figure out which one they should use.
It would save everyone a lot of bother if maintainers of these repositories took half an hour to update everyone that they didn't have time to maintain the repository and pass the baton on to someone / some people who do.
Instead of having to figure out how an existing piece of code works, update deps and merge a couple of PRs myself, I instead have to recreate the entire functionality from scratch.
In our original world, where you did release the code, I still have the option of creating my own library (with the benefit of seeing your implementation!). So by releasing your code, you've given me strictly more options, and therefore made me better off, or at least no worse off.
Think about this claim: ‘a creator of open source doesn’t owe X anything’. First, using a financial metaphor misses the point. Second, it is often used as a cliche and/or rhetorical device to shut down conversations about ethical considerations. Third, I get it: there are people that expect too much, which can encourage an (over) reaction from someone who shares an open source library.
Many people bristle when someone else uses the word ‘should’ in a sentence. I’d like software developers to be more mindful of what it means to participate in a community.
Who said anything about vetting?
More generally, I wonder about your underlying thought process and expectation. Were you somehow bothered when someone raised an additional related point?
The way we interact with each here other matters.
If the new maintainers cause problems, it's their problem, so the "you" in "you can't win" would of switched between maintainers.
If there's an implicit obligation, it seems to me it's on users, not authors. If you really need something changed you should fork/fix it yourself or talk somebody else into doing it. That right is baked into every major OSS license.
And that's taking into account we're the lucky ones that can work from home and keep getting a salary
Whatever I put outside is more to keep HR happy when they ask for a github link than anything else.
It is all a bit crappy collection from university projects, or tiny stuff I did on side either to learn an algorithm or a quick and dirty solution for something.
The good stuff I rather do it at work.
Yes you must read and understand everything or have trust in the publisher. Relying on the package name is going to get you in trouble. Sounds like a great exploit opportunity.
Turns out left-pad.js is on line 8571 of that 14+k line yarn.lock file.
How many React Native developers do you suppose have reviewed every line of code in every library referenced in that file? (Or even how many engineering teams at any React-using Unicorn size startups or FAANG have exhaustively reviewed all those lines of code?)
Is FaceBook a "trusted publisher" of React? Is npm a "trusted publisher" of Node libraries? Was Azer Koçulu a "trusted publisher" of left-pad.js?
(And it's turtles all the way down. Is Microsoft a "trusted publisher" of Windows? Is Dell a "trusted publisher" of bios? Is Intel a "trusted publisher" of cpu micro-code? Is Western Digital a "trusted publisher" of hard drive firmware? Is every unnamed silicon manufacturer and pcb and subcomponent assembly house a "trusted publisher" of the embedded code in their network card/usb hub/battery management chip/whatever?)
I _do_ agree with you, but these days it's very difficult, at least in much/most of the software world, to determine the height of the people/libraries claiming to be "giants" offering their shoulders to stand on. (And like with React, it's more and more difficult to determine which actual giants are standing on bedrock, and which have a foothold with quicksand uderneath it...)
When you include left-pad in your own project you should audit it. In the end you are the only line of defense. With react it's larger so you can trust others.
I am the sole maintainer of airbnb/lottie-android despite the fact that I left the company almost 2 years ago and it is used by tens of thousands of companies including Google, Samsung, Microsoft, Uber, Netflix, and countless others.
Doing it yourself I would just freeze versions.
In this case I find it odd for someone to keep maintanier status for a company repo they no longer work for 2 years after leaving.
I would have forked and introduced new changes in my own repo if I cared about the project. Let others follow if they desire new updates or force airbrb to assign someone to update. or better get airbrb to pay you to keep updating.
Now Zac probably isn't the sort of person who'd do that, but once you get to a project like React which has 10,000 or so dependancies - surely _some_ of those dependancy authors would do that, for enough pieces of silver...
As a community we need to accept that the above mentioned DOES happen. Pretending otherwise only hurts us all.
In fact, it happens very often when people are learning and exploring. So imagine I publish my shitty library "with a generic name and a description talking about how awesome it is". Imagine you're trying to learn $language. You buy into my deception and try to use my library. You get burned, and might be left with an impression that $language or its ecosystem is shitty, and never return, despite the fact that $language would suit the kinds of problems you're solving really well. If it happens enough times with enough libraries, $language may get a bad reputation. Preventing this becomes a matter of protecting the common good.
(Hmmm, just the greybeards. I could have guessed that I suppose...)
So if the project seems to be ignored (no issues), if it has tons of them and no response, you won't use it or use it only with caution.
Newcomer to langue or ecosystem should use popular frameworks and libraries, so that there is help available.
Some things may slip through the cracks, but filtering out most of the chaff can be done without reading every line of source.
As far as I can tell this is a node-specific problem. I would argue it's a byproduct of resume-driven-development, not of open source culture. I think the onus is on npm to guard against obvious click grabbing projects (like is-odd, is-even, leftpad...), but it's also on the JS standards committee to develop a standard library that doesn't need 1 or 2 line dependencies to function the way a reasonable human would expect it to function.
> sure: it is totally their fault for deploying something without carefully reading your code to figure out that it was a bit shitty beforehand... but should they really have to do that?
Yes, you should at least read through the README and take a look at the issues before using any project. Code with 0 issues filed, no forks, and no stars...should not be used in production without proof reading. You can get a benefit of the doubt if it's clearly a popular project (i.e. apple/swift, google/flutter), because at least then you know multiple people before you have tried it out and been satisfied enough to want to help out.
> if you bring something that you know tastes bad or will make someone sick to the potluck and put a little sign on it saying "gourmet enchiladas: much better than what you get at the store" and put it in the center of the table, it is still a problem
The problem is that this is subjective. What does "tastes bad" mean? Are you expected to know what will make someone throw up? Sure, you'd be a dick for serving raw chicken - but the raw chicken projects generally don't have READMEs in the first place, because they were never intended for usage by others. It's your fault if you incorporate raw chicken into your meal and get sick from it.
The problem is that some people view a package manager as a farmer's market while others see it as a restaurant. Should you serve gourmet meals, or are berries OK too? If you sell raw chicken at a farmer's market, it should be obvious to the consumer that they have to cook the chicken first before eating it. The problem is when a customer goes to a farmer's market expecting it to be a restaurant and gets sick from something they didn't understand.
EDIT: Not sure why this was downvoted, maybe people forgot that padStart and friends appeared in ES2015, long after left-pad was created
Now if you ask "but why?", ultra-small packages like this are popular in JS because of the lack of a standard lib. Lots of devs prefer to install a dependency for each one-liner utility rather than write them themselves.
The only added value of those packages is that they're usually unit-tested against weird edge-cases that you might miss if you wrote them yourself.
Edit: related discussion at https://news.ycombinator.com/item?id=20223190
When its creator removed it, they literally destroyed the foundation of those popular packages. That's what made it suddenly important.
Programming in JS is just this way.
I had to include moment.js yesterday just to format a date. Nothing fancy, but no easy way around it.
I'm observing this regularly. Currently a bit more in the Rust community since I'm more active there, but I think it's a thing that happens everywhere.
I think in most situations it happens is is incidentally: The people who wrote those packages do not actually have the experience to observe design and quality issues in their package. They might still be in university, or have a minimal amount of industry experience, and found working on an open source project to be a nice way to be creative.
And in one metric that they found for themselves, the might even beat very established projects - let it be performance or finding the new "ultimate abstraction". Therefore they are going forward to market the project as the awesome new thing - without knowing about other important metrics that their project does not meet.
I'm not sure how this can be improved. I think it would require experienced reviewers and curators that are willing to look into other peoples open source projects and help them. As well as authors of those projects to be willing to be mentored. Both is not easy. As an experienced engineer you have enough to to that you don't want to look into YetAnotherProject. As someone who wants to hack on a side project as much as possible you probably don't want to waste your time with talking to someone else.
If I've built a small library that does something useful for my set of needs, it's not crap software. It works perfectly well for my needs.
If someone then goes ahead and uses my library, without understanding what needs it satisfies and what it does not, how is that on me?
I release it to the world with the understanding that someone else might have the same requirements that I had when I built it. Why shouldn't I have released it?
As an extreme example consider content farms like eHow. After all, they simply publish some low-quality how-to guides, no one is obliged to read them. Why then are they so universally reviled?
> If someone then goes ahead and uses my library, without understanding what needs it satisfies and what it does not, how is that on me?
Being upfront and clear about the needs it satisfies is good documentation practice and plain common courtesy. If you did it and they still misunderstood, then yes, it is on them.
Publishing them is not using someone elses attention. And I dont go around hating on eHow. I do expect google to put them down in ranking over time and I do structure my queries so that I dont hit them.
Also, small one time open source project is not tweaking SEO like content farms. That comparison does not work either.
> We dont apply similar standards to blogs nor videos nor art - them being crappy is not "taking away our attention resource".
That's because the attention cost was driven way down by awesome information retrieval systems that we have (google, etc.). But the cost is still there and it is a good idea to compare it against benefits. Again, this doesn't mean that you should not publish anything.
> Publishing them is not using someone elses attention.
If you publish anything, you expect it to be found by someone (otherwise, why publish at all?). Voila, you've used their attention.
> And I dont go around hating on eHow. I do expect google to put them down in ranking over time and I do structure my queries so that I dont hit them.
This just corroborates my point that the cost is real. In this case the cost is paid by google (they have to expend resources to fight SEO spam) and you (you have to reformulate your queries).
> Also, small one time open source project is not tweaking SEO like content farms. That comparison does not work either.
I'm afraid without concrete examples we are talking past each other. Of course a small-time project that is clearly marked as such is totally OK, but the original post by saurik mentioned squatting common names and overpromising on features, which is definitely into the SEO territory.
The reality is that when you publish your package someone else who is trying to get something done is going to use their package manager's search feature to look for like "jsonrpc" and find your half-assed for-personal-use-only jsonrpc library as one of the results; great... now, they have to look at your readme file, open issues, and maybe do some kind of code review to verify whether you are taking this seriously enough for them to rely on your package or not. Of course, a lot of times they aren't even skilled enough to do that analysis correctly as they are just getting into software development and that is hard to do. Worst case you end up higher in the search results than an actually-useful package because you sniped a name like "jsonrpc" or "jsonrpc-client".
This is then the point where (and I am not saying you yourself do this, but this is the developer I am most upset with, and this is as someone who long ago mostly gave up using anyone's packages and now mostly deals with this by being the "wet blanket" constantly trying to convince other people about how low quality some random package they shouldn't be using really is) if your readme file talks about how awesome your package is and has a bunch of past tense descriptions of things you didn't get around to finishing and never will--things you might not even accept patches for or feedback on because this was a project you did over the weekend and are now done with and you didn't really sign up to be an open source maintainer--you aren't just using other's attention, you are outright being a jerk and need to really ask yourself what you are doing by publishing your package in the first place :(.
I second the comment above about having a honest description to waste other people’s time.
So yeah, it is totally OK for your open source library to be shitty, but please state this clearly in README to save everyone's time.
As user, it's clear that you need a feature which you found on an unpopular library. Now rather than be skeptical and research the library, or wrap it under yours so you can replace it later, or develop your own, you decide to blindly use it and blame the author.
Install packages from:
- PyPI (and other indexes) using requirement specifiers.
- VCS project urls.
- Local project directories.
- Local or remote source archives.
Although I’m not quite sure how you’re using “for public use” in that sentence.
Installing from a generic git URL tends to work just fine, even if it's a bit more typing.
Package repositories can be open to all developers or curated by software distribution maintainers. Being able to publish an open source project without dealing with Linux distribution maintainers is a major selling point of programming language package managers.
Why even let people publish packages if they're not meant to?
> it is totally their fault for deploying something without carefully reading your code to figure out that it was a bit shitty beforehand... but should they really have to do that?
Absolutely. Using someone else's code means implicitly trusting them. Everyone should at least check out the package's source code for quality, sanity and signs of maintenance.
I don't think GP even so much as insinuated in their post that people aren't meant to publish packages in general.
So why even let random people sign up a developer account and publish packages? Maybe they need a separate curated "serious packages only" repository.
This is how disasters like leftpad happen.
The bar for publishing software is extremely low and we pay the price every day in terms of security, bloat and complexity.
It has nothing to do with how easy it is to publish things. Also, adding own left-pad once disaster happened is quite easy in node.js modules system.
I know free software debaters and open source license philosophers love to hate on this one, but the fundamental core concept of "more importantly, it should absolve authors of shame, embarrassment and ridicule for ugly code" in the context of them choosing to release code or not is a great idea I reckon.
(But I agree wholeheartedly with the thrust of your argument, and am of the opinion that if you spent more time on the logo design or website marketing copy for your library than you did writing the code, then "You're doin' it wrong...")
The craziest click-to-accept clause I have ever read.
(or in retrospect, perhaps "equivalently" rather than "alternatively")
I love the project. People at my last few companies joke about it. But it's so fun.
Who cares if it's shitty. Ride bikes and write code.
So I closed the issues on those two projects that got most low-quality issues. People started to open PR to tell me I was wrong and I should open the issues. This cemented my decision, oh the entitlement of some people.
Did those pull requests have code changes?
+If you spot a bug or any other issue you may go to hell because this software is officially Bug Free(TM).
If someone spams me, I will ignore or retaliate by reporting as spam. If someone sends a low effort question, I might politely tell them to rtfm. If someone makes an effort to articulate a problem, even if I disagree, I’ll try to give them a reasoned response.
And if I genuinely have no interest in any interaction I’ll make sure to disable issues/comments or otherwise communicate this intent.
Do you see the contradiction here?
He said there's no "absolute" obligation, but there are some by virtue of us living in a society.
If you say that there is no obligations, but also that you should follow some social expectations, then you’re contradicting yourself. It’s just a nicer way to say that people should behave according to what you consider to be acceptable.
Btw, which society rules do you mean? Because you have a lot of differences in different places regarding politeness and other social obligations.
The entire discussion is at the level of social expectations.
Correct, I think we agree on that.
> The entire discussion is at the level of social expectations.
No, this statement:
> No, there is no obligation. But there’s a thing called courtesy.
Is actually “No, there is no legal obligation. But there’s a thing called courtesy.“ And here the contradiction falls away and the discussion turns to whether there is a social expectation to be courteous. On that point my (and the above commenter, I suspect) would say that yes, of course there is an expectation of social courtesy. There’s one in every other setting too, so why not here?
As a Spaniard living in Japan, what social rules should I use to apply my social courtesy on Github?
In my experience, there are no objective social norms or definition of "courtesy". What's polite in one culture might not be in another. Projecting your own values onto others isn't helpful.
So what you're saying is that if a person puts a lot of time and effort into opening an issue, they're entitled to a response?
The maintainer has to justify themselves to noone, and only the maintainer knows their aims, contexts and ambitions for the project. That long, detailed issue that someone submits could have been the 50th one they saw that week about the same thing, which they'd already decided they won't fix.
I recently opened a couple of PRs on a small project, one of which looks like it'll be rejected and the other hasn't visibly been reviewed. This is fine. If I need these things badly enough or soon enough, I'll fork the project - I'm certainly not entitled to anyone giving up their time reviewing my code or agreeing with me.
If you put some effort and need help with the project, I'll try my best to help you. If you come demanding free support for your project, I'll just close the issue saying this is not the place.
This is amazing, thank you so much. Typos are very troublesome and they slip through the cracks too easily. A typo PR or issue will get merged 100% of the times in my case.
I meant that I closed the issue section, not individual issues. For individual issues I don't recall closing a single non-rude one without at least a short explanation.
The problem was when people came like "I am using this library, can you debug my code?" and pasted a 500-liner, or like "this doesn't work on my XYZ system, fix it", or when they were just rude or demanding.
I've met some wonderful people BTW, and would also not trade that for anything.
Some users are overly entitled, but some maintainers are self-absorbed douchebags. I've seen both sides.
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?
Also if it's a real issue that you won't fix you should at least leave the issue open so other people know.
IMO you can definitely be extremely grateful for someone's contribution and also think they are sort of rude, not incompatible views/feeling.
I think you mistakenly switched the roles there. You are not isolating a bug for the author. The author is using their software and is happy with its current state. It is you that is being hit by a supposed bug, and you are isolating it for yourself. Then you are expecting the author to do the additional work for you and handle your supposed fixes. Don’t get me wrong, you’re probably both helping each other in the best spirit of open source, but it’s not you who’s the ideal of generosity there.
1. For you, since you are nice and helpful debugging it and fixing it for you and others so I want to make it easy for you to use the working code.
2. For other users that might hit the bug, for every PR bugfix there are likely N people hitting the bug.
3. For me in case I hit it in the future.
4. For correctness sake.
But not all bugs are straightforward, many have side-effects or disadvantages that I might not be comfortable merging straight away. So I have to evaluate how long it'll take me to review the PR and whether it's even worth-it (the vast majority of times PRs are worth-it, but issues are a hit and miss).
Where does that bad feeling come from? Does it come from the fact that you feel like you're owed a response? Do you get the same feeling when you email strangers and they don't respond?
> Also if it's a real issue that you won't fix you should at least leave the issue open so other people know.
> IMO you can definitely be extremely grateful for someone's contribution and also think they are sort of rude, not incompatible views/feeling.
You're not entitled to gratitude. Assuming that people should & will run their own projects according to your values around courtesy is a little self-centred.
If you need the bug fixing and the maintainer isn't doing it fast enough, just fork it. This is the point of open source.
It's just the time spent for me, I mean if for some reason I put like an hour of my time composing an email to a stranger and they didn't respond I would unhappy. It would be my fault but I would still be unhappy.
I agree that no one is entitled to have everyone act nice to them. I just think it's nice to tell someone why you're closing their issue.
> If you need the bug fixing and the maintainer isn't doing it fast enough, just fork it. This is the point of open source.
There's something about putting time and effort into writhing a good bug report that forces you to truly try and understand what's happening.
But also had some C libraries for Arm STM32 and only ever got solid pull requests and people eager to help. You see the same thing in IRC / Discord channels of those technologies.
which will be interesting to see if you ask them for payment for fixes, would they pay?
I think a lot of this has to do with the effort you put into community management. We put tons of energy into making it easy to make good contributions: PR/issue templates, we're on slack, we respond to emails, we make it as easy as possible to get your code in as long as it passes tests. It's a lot of effort and I can't imagine doing it for something that was just a personal project, but I think that's how the bigger projects deal with it.
This is besides my fulltime job, friends and hobbies. So I don't really have much time for growing a community, I've done some effort in the past when I had more time and it worked fairly well, but I found it to be very project-oriented in general so if you do many smaller projects (as opposed to few large ones) the community approach doesn't scale well.
I don't encounter many mean/crazy people! I can count them with one hand. I find few entitled people, but most people I've found are nice.
If it's a user-facing project, then people will approach the project's "github issues" as a company's support line, and feel a bit more entitled.
If it's a library or plugin for developers, people generally have more empathy and appreciation towards the maintainers.
I think maybe it has to do with:
2. What percentage of developers were forced to use your tool/library against their will by their employers or forced upon them as a dependency of some other tool.
If a project is overhyped, then developers will be disappointed by reality and they will complain. The best you can do is try to set realistic expectations.
If a developer was forced to use your library by their employer (or it was forced upon them as a dependency of another tool/library that they're using and your dependency was throwing some weird error) then they will also complain. The best you can do about that is try to make your library work 'out of the box' as well as possible and make it work well in as many environments and operating systems as possible. Regulating hype by setting realistic expectations can also help prevent employers from forcing their developers to use a library. You should use more technical terminology instead of business buzz words when describing your project. You want to attract developers, not project managers.
Oh boy you'd have thought people had paid thousands of dollars for the code the way people talk to the maintainers.
The one thing that gives me pause is the prospect of having to manage a bunch of unfriendly feature requests and bug reports. Here's hoping we find ourselves in a virtuous niche.
It's about time that programmers recognize that a "Delete GitHub" movement is as valid and as needed as "Delete Facebook" or "Delete Twitter".
GitHub is not really about software development. GitHub is yet another social networking site, only it's for busywork masquerading as Real Important Programmer Stuff.
Essentially; do publish all work you possibly can, simply be clear about what the software does or does not do.
I am very guilty of not doing this myself. I throw together some bit of code that is useful to me, and dump it on github with no explanation of what it does or how to use it.
As a bad example, I'd encourage everyone like me to put in a bit of effort to explain what your code does, so that when someone stumbles across it they have a way to give it a try and see it doing something.
Today though, every popular repo has hundreds of forks and there is no easy way to identify forks that are more actively maintained. I understand it is a non-trivial problem, but hopefully Github has the talent to solve this problem.
At the very least they can make it easy to ignore forks where
1. changes have already been merged upline
2. forks that only have cosmetic changes of imports (happens a lot for Go repositories)
This will allow the developer to pass the torch, so to speak, to someone else willing to maintain their own fork.
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”.
Since my employer told me I was no longer allowed to work on it at work, I have felt quite a lot of guilt about all but abandoning fixing bugs and reading the mailing list. I've been working on a "next generation" version, almost a rewrite, but I don't see a clear path for releasing it in a way that helps people still using the current version.
It may be self-serving, but I am really going to try to take this essay to heart, and not beat myself up everytime a weekend goes by that I don't spend working on my project.
"You should rewrite in" / "Why does't it do" / "Make it do".
It's nice that people are using it. I generally (try to) assume this is a language/cultural thing, and people don't realise that they're coming across as a bit rude in English.
But, it would be nicer if people approached commenting on OSS by first thinking "Author is doing this for fun, unpaid, and I'm getting something nice out of his/her time", THEN writing their comment.
I'd get the same issues raised, and that's fine. But the language might read a bit nicer.
One thing I would like to suggest is to have a question in the feature or bug issue template to ask what people use the lib for and what they like about it. Maybe even set expectations.
I think there's a lot of scope for changing the way that comments on issue trackers and pull requests are taken in order to make the interactions more human and friendly.
Sure, at small companies where developers interview you, or maybe if you link to a specific relevant project in your cover letter, you might get a pair of eyeballs. But I think people vastly overestimate the readership of their repos when looking for jobs.
It got cross-posted across the internet and a ton of stars and even referenced in some else’s project repo as a competitor/alternative and reasons why theirs was better!
This experience really made me smile. Nobody even tried to run it.
It's uncommon (and my anecdote is part of the "exceptions" for sure), but it's very very motivating when it happens.
On multiple occasions I've had to talk them out of not wanting to even interview based on one random file in a random repo by the interviewee.
Because of this, when I start applying I hide all my repos that I'm not mostly proud of.
I wouldn't want to work there and they would have saved me so much trouble.
Bad GitHub code means nothing. Good original GitHub code means something. And the less these orgs realize that the easier it is to get engineers that are otherwise unappreciated.
Whenever you evaluate a candidate on any axis, you have to be very careful about whether or not you’re judging them on something related to work performance or not. In the case of GitHub profiles, you’re also evaluating someone based on whether or not they have the post-work time to contribute to open source work, which is unrelated to their ability to contribute during working hours.
I’ve hired enough amazing engineers who didn’t have time for open source contributions that I’ve decided that open source work is not a meaningful metric for evaluating a potential hire.
Also, my GitHub profile is not impressive; it would be deeply hypocritical for me to hold candidates to a standard I couldn’t meet.
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.
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".
Besides normal open source contributions and semi-maintained side projects my own github for example is full of one off scripts and weekend project repos that are interesting for an average of N<10 people per year, I still put those up because that N is larger than 0. You won't find the code quality your previous post asked for, or even any test code in some of them. That doesn't mean I don't have any. Just like there's great developers with zero presence on GitHub out there. It's just one of the many signals in the hiring process, as long as I don't see a major red flag in the profile it mostly informs "this person works on interesting stuff in domain X / similar interests like my other devs / extensive experience with platform Y". I don't have time to look at fancy coverage badges in all 30+ repos of a profile, there's plenty of time to talk about specifics later on. I treat github profile links like any other, say to a candidate's personal tech blog. The mere existence is nice and I'll give it a glance but that's about it.
In most domains I've worked in other parts of the CV and public presence are far more informative about a candidate, shoehorning pseudo-scientific metrics about code or test quality on candidate's github profiles seems counterproductive. People have other things to do in their life than maintaining recruitment-friendly github profiles, expecting one is not much different to the odd practice of unpaid take home exercises imho.
If someone doesn’t work out we just let them go after half a year. So far that hasn’t actually been necessary.
Does the distinction matter at your company, or is the primary metric "good enough"? Is this industry standard, or does it vary by company?
I definitely don’t rely on their GitHub info for that. In the interview process in general, I don’t expect this with junior developers, only senior+ developers, and then I look for how deliberate the developer seems to be with design trade-offs in their coding exercises and their answers to “tell be about a time when...” questions.
Does the distinction matter at your company, or is the primary metric "good enough"?
The distinction matters, but in my experience interviews produce very noisy signals for this trait. (1) How often do you design API’s in half an hour? In practice the decisions that affect long term maintainability happen over days, not hours. (2) Evaluating this requires a lot of subjective judgement from interviewers, and experience tells me that no interviewer is as objective or insightful as they think, myself included. So instead of trying to answer that question, I just look for a deliberate process of enumerating and deciding trade-offs, with answers that are in the ballpark of sane.
I wouldn’t call good enough a metric, more like a philosophy for hiring. I look at many unrelated traits in an interview, but I explicitly reject the idea that the interview is accurate enough to conclude something like “this developer is a net reducer of technical debt”.
Is this industry standard, or does it vary by company?
The interview rubrics I’ve seen all use holistic definitions of “good enough to hire”, if that’s what you’re asking, but based on what I’ve seen as an interviewee I highly doubt there’s an industry standard the way you’re asking.
What I'm really trying to fish out is: if a developer is significantly better than the competition relative to his years of experience, how is he supposed to communicate that? How does he actually get paid commensurate to that extra effort? In your experience is it even possible?
As far as I can tell the only way to really do that reliably is either work on a respected product & basically make an impression outside your company (crapshoot) or show what you can do via open source. I can't see how I could communicate it otherwise.
The answer to your question depends on what your answer is. There's no single objective measure of "better". If you're in a big company, the thing that sets a senior engineer apart from a strong almost-senior engineer is mostly about soft skills, so if you're a strong almost-senior engineer trying to convince someone to hire you as a senior engineer and you're focusing on communicating your coding feats, that might be sending the exact opposite of the message you intend. But if you pivot the same concept to "improving the people around you" it probably works in your favor.
There's no universal way to do it, because it depends heavily on what the hiring company/team values, so my personal advice is to (1) focus on your particular strengths, (2) assemble a portfolio to back it up, and (3) package it based on what the team/company values. It doesn't have to be open source. As a hiring manager (to be clear, I was one but am not anymore) I would have happily accepted any incidental materials that interviewees wanted me to see.
What do you consider to be your particular strengths?
I'll give an example in my own case. I was a product person who became an engineer. I have a "senior" title. In terms of the number of years I've been out of college and working, the "senior" title is pretty typical. However, I had actually only written code professionally for 1 year before I got the role. (Though I've actually been coding since I was ~13.) Whether I deserved it isn't for me to judge, but I think my story counts as an example of what you're asking about.
The way I maneuvered it was:
1. I was historically an algorithms nut, which means I do particularly well in a specific type of interview, so I targeted companies that interview this way.
2. As a former product person, by necessity I have over-developed product instincts and soft skills relative to engineers with similar amounts of experience, so I made sure to package that well and target roles that asked for those things. My branding was basically: "You want me because I'm really good at aligning people to get things done without authority, especially when there are lots of stakeholders." Engineering teams almost always prefer having more of that in their engineers to reduce reliance on PM's.
3. I networked like hell. Seriously. Nothing is better at telling hiring managers that you are a dark horse than a mutual professional acquaintance telling the hiring manager that you are a dark horse.
4. I sent out a LOT of applications. I think I sent out somewhere around 50 applications for roles at various levels from entry level (<= 1-5 years) to senior level (5+ years). The vast majority of entry level roles I never heard back from simply because of the number of years of experience. It is what it is. Their loss... or that's what I tell myself anyway.
I don't think any one of those four things was singularly responsible for the eventual outcome, but I can say for sure that they all made a difference. Also, I can say that #3 was the single biggest factor in my yield rates. If you look at the split, I got a first interview in something like 80% of my referred applications and 10% when it wasn't a referral. That's both evidence that networking really works, and evidence that the hiring pipeline sucks. The best way to consistently punch in above your general metrics is to not go in through the front door.