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.
Unfortunately, DINKs are hard to compete with professionally. Old boss used to loudly thank my colleague for doing tickets on the weekends, and too often people seem to assume I want to spend my weekend "brushing up" on some implementation detail for a project I don't care about. Even "why doesn't he come to after work drinks?" Is hard to answer with "because my spouse is _also_ an exhausted wreck at the end of the day and I already barely have any time for them, much less my real friends, much less you lot".
That's terrible. I am a manager and actively discourage people from working late / weekends. I find it's not sustainable. People who do that, regardless of children status are much less predictable in their output. They go through peaks of productivity and then they crash. It also ends up happening that they work on the wrong thing because no one is around at night or weekends to answer basic questions that may unfortunately not be in the ticket. Some of our employees with highest productivity have kids. I think your story means you should look for a new job when it is possible for you.
> It also ends up happening that they work on the wrong thing because no one is around at night or weekends to answer basic questions that may unfortunately not be in the ticket.
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'm sorry, but I don't think that's what they were saying at all. To me, it sounded like they were saying that when a developer works alone at nights or on the weekend, they cannot ask other members of the team, or the person who originally filed the ticket, any questions. Thus, if the ticket is vague, or if they have a question about a part of the codebase they are less familiar with, they have to spend a lot of time trying to divine the answers themselves when they could just walk over or message their colleague for the answer on a normal work day. Spending three hours rederiving trivial knowledge that other members of your team already know (such as which package something is in, or the exact set of inputs that reliably reproduce a bug), IS spending time on the wrong things.
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.
> To me, it sounded like they were saying that when a developer works alone at nights or on the weekend, they cannot ask other members of the team, or the person who originally filed the ticket, any questions.
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.
This is a very commendable default approach. Let me suggest that there are also people who just happen to be that way naturally.
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’ve somehow managed to work in this industry twenty years and never be pressured to work on weekends, except for occasional emergencies or exceptional releases, and I’ve never felt pressured to happy hour with anyone. In SF, no less. I’m also a single co-parent, from the time he was born.
I mean, this isn't necessarily a 'dual income' thing, this is a 'cares exclusively about work' thing.
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.
Nowadays, I don't feel anymore like I need to compete professionally. I've got a decent savings account, half my house is paid off, my family is healthy, and work is interesting. Why would I need to compete with anyone?
Because they're bidding on the same house as you, and can push for slightly more cash at work, presumably. But it's amazing what a paid-off house does for your assertiveness at work.
This seems more in certain cultures than others - American and Japanese from my anecdotal experience. I worked with Europeans (French especially), they don’t seem to wear long hours as a badge of honor.
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
Agreed... I remember a study on “do kids make you happier” and their conclusion was “kids make you happier if you want kids”.. people who didn’t want kids but had them or wanted kids but couldn’t have them were sadder, but people who didn’t want kids and didn’t have them were just as happy. Which I guess makes sense... people are happy when they get what they want!
Sure I could have rephrased it along the lines of "you have the invaluable blessing of children, and surely that's more important than a 15% pay rise?".
Your edit got under my skin way more than your comment did.
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?
Only if you care personally for the kids. Pick up a history book, filled with famous persons who had lot's of kids, but they were raised by family and staff.
Maybe to someone who isn’t ambitious or intelligent but personally, I’d rather write a great book or make great software. I believe, like Proust, that art is how you reach immortality.
What’s dumb is to tell people you’re better than Proust because you popped out some brats.
Although I appreciate the sentiment behind this very romantic comment and I understand that it is mostly addressed at kindred spirits who can relate in parenthood, I think that it's important to nuance the idea a tad bit. The world is already filled with too many people mindlessly following tradition. When in doubt about how to make themselves happier, they don't dig much before reverting to the status quo: having a kid. The promotion of the idea that we're realizing our purpose in life by procreating has undoubtedly caused a lot misery, as a substantial portion of those who experimented with parenthood failed to find what they hoped for and many children ended up suffering for it. Human beings are not just mere biological entities fulfilling some function of nature. We are blessed (or cursed) with complicated minds that make us appreciate a lot more to life than raising children.
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".
Why would you feel bad? The whole point of open source is they could have done it themselves, if they wanted some integration they needed and you didn't.
And then they could either contribute it back, fork your project or just keep it to themselves, if the license allows it. At any rate, you already helped them...
People often act very entitled about open source I've found.
You'll often get angry irate emails/issues raised demanding you help them or add a new feature or whatever. Some people are just clueless and need help, others are just dicks.
It is often not worth the hassle in my opinion, but then everyone's circumstances and motivations are different and I am glad that a lot of people do think it is worth it.
Some of the commenters in that issue have a very regressive and myopic stance. Raising such a public ruckus will heavily disincentivise scientists from publishing their code in the future. Decisions will still be made, but in the dark. There's a certain amount of self-stroking going on there with people feeling better by putting down code produced by non-professional programmers.
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.
I don't think anyone is saying the code can't be better or even that the results might be wrong (I don't know as I haven't spent much time going through the codebase).
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).
I don’t doubt it, but covid-sim is not the best example of this effect. In this case, people are worried that poorly written simulation code is informing policy decisions that affect billions of people. They are not demanding that it should be fixed, they are demanding that it should not be relied on in its current state.
They're worried that there isn't testing code to prove that it's correct. If it's proven correct in other ways, it doesn't need unit tests.
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.
To be clear, I am not arguing for or against the validity of the claims regarding covid-sim. I am only saying that this is not a good example of the effect where people feel entitled to get open source code that fits their needs.
Dunning-Kruger powered software developers with beliefs that they are in any way qualified to say that mathematical simulations checked by dozens of actual scientists with PhDs are not valid ask that results are ignored because there's no unit tests.
I don't even know where to begin with this, it's so insane. It's extra funny because John Carmack was the one who did a lot of the refactoring of this code. It's also not remotely true that billions of lives have been disrupted on the basis of this code being correct.
This is exactly why scientists don't release their code.
Another reason scientists often don't release code is that code is not considered the valuable artifact produced by research--in more methods-focused fields in particular, it's instead the mathematical model, as embodied in some latex in the published paper. "Reproducing" the results then doesn't consist of trivially rerunning the same code, but in reimplementing it, possibly in a different language. This could maybe be seen as valuable in that the reproduction will surface both implementation errors and logic/modeling errors (though, really, having the source facilitates both).
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.)
Yup. This whole experience was immensely frustrating. First people complain that the code isn't open source and as soon as it is available suddenly there are piles of people swooping in to shit on everything. That's not going to make scientists write better code. It is going to make scientists refuse to open their code.
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.
> People often act very entitled about open source I've found.
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.
I have a very simple Firefox extension that inverts the colors of sites, I wrote it as I needed something that would just give me dark themed web pages when my baby was asleep next to me. You would not believe some of the reviews and requests (ultimatums) I got.
The funniest ones are those who need your thing for their professional work, yet treat you as if you were a fully paid contractor at their beck and call.
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.
I think it's fine to not have time to maintain code you open source. However, if your library ends up gaining a significant user base and you don't have time to maintain it, then I think you have a duty to either:
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.
Vetting a maintainer is non-zero work. But it's also not all that much. Especially if said maintainer has already contributed meaningful PRs against your repository.
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.
Sure it would save everyone a lot of bother, but consider the alternate universe where you didn't release your code at all. There's no original repo, no idling PRs, no forks, no "community".
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.
I think we would benefit if more people think about individualist and communitarian views on ethics.
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.
Generally, writing ‘who said anything about X’ strikes me as unproductive for discussion. At the least, the tone could be improved.
More generally, I wonder about your underlying thought process and expectation. Were you somehow bothered when someone raised an additional related point?
Because people also complain when new maintainers are added and those maintainers cause problems or even abuse the project to insert malware. You can't win.
Well maybe those people don't have a valid complaint, but then that wasn't part of the original post; I was looking for a response from fovc specifically.
If the new maintainers cause problems, it's their problem, so the "you" in "you can't win" would of switched between maintainers.
I really disagree that authors have a general obligation to do anything with their code, at least as far as support is concerned. If somebody signed up formally to be a committer or made some other explicit commitment that's of course a different matter.
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.
Licenses do not codify obligations, they codify legal requirements. Getting someone to replace you if like holding the door open after yourself: no law will force you to do this, but people will still say it’s polite for you to do so.
A bit tangential but it's been very relatable to me lately : 80% of my coworkers : OMG working from home gets you so much done! I've passed this and this certif and also did that side-project. Amazing. And you ? Well, I've tried to manage being a good parent while working with kids at home and god knows that was hard enough.
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.
I find many prolific GH OSS authors to be single, but do code instead of gaming like you said. Or their job lets them OSS some of the code they use at work while on the clock.
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.
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...)
In react's case you put your trust in facebook and because of the size most issues get discovered and someone has an article on how to fix before breakfast.
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.
Let's say this doesn't get updated I don't see a problem. It will continue to function as it is until it gets outdated and replaceed. Let's say it changes and does something evil, hopefully Google, Microsoft will catch the issue. If they don't someone will and people will stop trusting react or whatever product pulls these changes in.
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.
Lets just say someone at booking.com or tripping.com or some other hungry and less-that-totally-ethical AirBNB competitor works this out, and offers to buy the library or pay Zac $bignum in return for adding in some "additional analytics" aka industrial espionage allowing them to see searches/bookings made by users of apps with the library embedded.
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...
What if I have no reasonable way of fully understanding the code nor being able to judge the author on their trustworthiness (even disregarding that this isn't constant).
As a community we need to accept that the above mentioned DOES happen. Pretending otherwise only hurts us all.
> 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.
There are many things short of reading the code in full you can do to lower the chances of this happening. A lot of half-assed libraries have obviously incomplete APIs that you can notice if you think about the interface provided and the nature of what the library claims to be doing. You can also look at repo activity; was it all coded in one week 8 years ago and never touched again? Does it have lots of outstanding issues?
Some things may slip through the cracks, but filtering out most of the chaff can be done without reading every line of source.
This. In my experience, GitHub issues and PRs tell you most everything you need to know about an open source library: if issues are responded to (and how quickly), the attitude of the maintainer with regards to new features, etc. Most of this can be gleamed within 20 minutes of browsing, and when you combine that with a quick 5-minute look at dependencies and tests, you can make a pretty good, educated decision about whether to use the library, and those 25-30 minutes save you hours or days of potential headaches down the road.
Most of time it's just trust. It's not possible to read through node modules, or reason about C compilers, or even inspect the source code of the operating systems.
> 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.
While `left-pad` certainly wasn't the most optimized implementation, it wasn't a "click-grabbing" project of the sort saurik was positing. It solved the problem the name suggested it would solve. The fallout around it really didn't have anything to do with "resume-driven development"
EDIT: Not sure why this was downvoted, maybe people forgot that padStart and friends appeared in ES2015, long after left-pad was created
off-topic: I still don't understand the use case that left-pad solved. I'm not into js at all but why do you need a dependency to add space to text? I'm asking honestly, I just don't get what the use for this was.
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.
the small libraries are best compared to stackoverflow code snippets. Instead of reading and copying a solution that may be out of date, you can use a (theoretically) tested solution that receives bug fixes. In many ways it is superior to the copy and paste of lore
You're misunderstanding, what is the use-case of that specific package? like I've never found myself needing to pad text on the left, just trying to understand why this was such an important package.
Probably for command line tools that need to add some level of hierarchy into their output. You can add 1 to pad length and pass it to a subcomponent to display its output.
I don't have any use for it either, but this package is not important by itself. It happens that this package is (was) at the very bottom of the dependency chain for some huge packages (like Babel, Webpack, popular frameworks, ...).
When its creator removed it, they literally destroyed the foundation of those popular packages. That's what made it suddenly important.
Yes, dates are very complicated. But that doesn't stop pretty much every modern language from having good built-in support for doing this, because it's such a totally common task. JavaScript is such a mess. It doesn't even support integers, for crying out loud, let alone decent date/time/timezone handling. That moment.js is the most popular band-aid to fix this, despite it having a nasty gotcha API that mixes mutable and immutable functions/types in confusing ways just rubs salt into the wound. Heck, you can't even compare two moment dates with inequality operators without either casting them by prepending a plus sign, or calling functions - it just silently does the wrong thing.
Silently? Since when is comparing objects in JS with (in)equality operators the right thing to do? There's no operator overloading nor special symbol you can implement in objects to make this work seamlessly ever. Casting/stringifying or calling functions is the only way for all objects.
The module system in Node.js (not ES6 modules) makes it super easy to use modules because a module is bound to a variable and you can require the module from anywhere and it will be scoped to the function. It's like if all code in the global JavaScript collective is available in global scope.
> 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?
Most of the time yes, but it is not so simple. There is a common resource that can be described as "attention of people who are looking for a library for X" and every time you publish a library for X you use up a bit of this resource. Most of the time this effect is small and more than offset by the value of your code, but it is not zero and overusing this common resource is a dick move.
As an extreme example consider content farms like eHow. After all, they simply publish some low-quality how-to guides, no one is obliged to read them. Why then are they so universally reviled?
> If someone then goes ahead and uses my library, without understanding what needs it satisfies and what it does not, how is that on me?
Being upfront and clear about the needs it satisfies is good documentation practice and plain common courtesy. If you did it and they still misunderstood, then yes, it is on them.
I find this standard ridiculous. We dont apply similar standards to blogs nor videos nor art - them being crappy is not "taking away our attention resource".
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.
I acknowledge the difference, but it is quantitative, not qualitative.
> 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.
Ah yes, I certainly have never seen anyone complain about the signal-to-noise level of low-quality blog posts and videos about topics where people are trying to learn about something like COVID-19... oh, wait ;P.
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 :(.
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. If you are actively marketing a project, you are declaring yourself open to criticism. You don't get to play the "what do you want for free?" card and say "my thing is totally awesome and you should use it!" at the same time.
Yes you do. I do that all the time. It just depends on who you're talking to. You can usually tell within a very short period of time who is going to get invested and add value, versus who is going to fall behind and demand a disproportionate amount of attention.
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.
Pip does not need a package to be public in order to install it at all, I’ve installed plenty of packages from tarballs and directories just fine. From the docs[0]
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.
I meant to say private use, not public use. But if I want to install from pip over the internet, which is my most common use case it needs to be publicly accessible, right? Which for me means GitHub, bitbucket, pypi, or some other bespoke solution just to avoid "publishing" something for my own private use. Or do I misunderstand?
I could do lots of things that would be unnecessarily burdensome for the dubious benefit of having my package unpublished. If it's acceptable to install it on a local network I can just do it directly from a normal filesystem.
I know about private repos. The hangup was installing from them. Last time I looked up how to have private python packages the the impression I got was "It's not possible." But now with a single Google search I see that it's very much possible (by using ssh). Not sure what changed other than two years have gone by.
This is why I really liked the approach of using a github username as a namespace for rubygems, it lets you publish things but with some indication that it may just be for personal use.
Yeah the useful thing is namespaces, I agree it would be good to not tie it to any given platform. I remember the cargo (rust) folks discussed including some way to have a namespace. I don't remember the details but I was disappointed they decided not to go that route.
You can install directly from GitHub, bitbucket, etc. with pip, BTW. My point was that if I want to have packages for private use installable over the internet with package management tools for various languages, I have to put them on the public internet, or jump through some hoops.
Package management tools for both Rust and Go and JS do support direct github urls with minimal boilerplate. You have no reason to make something public unless you want to.
Using pip, and possibly other tools, you can try using a .netrc[0] file to manage login credentials for private repositories.
Although it is a cleartext file (so you may need to manage access to it, for instance when using it in CI), at least your credentials will not show up in log files.
> 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.
The argument was: only packages which are good enough for production use ought to be published on official package repositories. This allows people to assume that all packages on the repository are stable, well maintained, good quality software without manually verifying each dependency.
So why even let random people sign up a developer account and publish packages? Maybe they need a separate curated "serious packages only" repository.
> Being able to publish an open source project without dealing with Linux distribution maintainers is a major selling point of programming language package managers.
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.
Left pad disaster happened because 1.) npm took away another authors project 2.) npm makes it overly easy to unpublish already published projects. That is ridiculous.
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 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?
It's not a child. It's a hammer. Somebody put it in the community shed so others can use it. If it breaks or somebody needs a nailgun, that's not their problem. I'm glad if somebody lent me their hammer so I don't have to buy one, even if it's not the best.
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.
No, there is no obligation. But there’s a thing called courtesy. And as humans there are certain social norms.
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.
I’m not saying this to be pedantic. And I’m not denying that there is some social expectations when living in 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.
Ok, so the problem here is that “obligation” has two meanings, and they’re being conflated here. One is pretty close to “being courteous to others” and the other is “you must do this”. When people say “maintainers have no obligation to anyone”, the point to the license where it usually says something like “THIS SOFTWARE IS PROVIDED AS-IS WITH NO WARRANTY” and you can tell that it’s the legal “must” definition because it’s in all caps and written in a way that nobody actually would write. So that means that nobody can sue the maintainer when they don’t do something or the other. All good, right? Well, now the question being posed above is “does this mean that the maintainer can also be rid of their obligations in the sense of courtesy, not legality?” And now since there is a difference in the definitions it is not contradictory to want to say “yes” to the second question. And yes, you are correct to say that these differ based on circumstances and location: that’s OK, we don’t judge them in a court of law. We do, however, judge people for their failings to meet societal obligations, based on our personal judgements.
> There is no reason to discuss legal obligations because that part is covered by licenses.
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?
You are not "gingerlime" who said that, I understand the original as "moral/social obligation" and not "legal obligation" but you seem to be putting the word "legal" on the users' mouth by saying what they "actually" mean?
As a Spaniard living in Japan, what social rules should I use to apply my social courtesy on Github?
I am gingerlime. I simply meant obligation as MUST and social norms / courtesy as SHOULD. So I guess technically you’re correct that it’s not a legal obligation, but I think the GP’s point is valid.
> No, there is no obligation. But there’s a thing called courtesy. And as humans there are certain social norms.
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.
Most cultures share some general social norms, such as courtesy to others. I would say it’s actually more unhelpful to dismiss norms entirely just because they have variance.
I think they mean they disabled issues altogether on the two github projects. I would give the benefit of doubt and assume they went through and responded to all open issues beforehand. Maybe even put things in a "known issues" section of the readme.
> Of course some people are low effort issuers, but some people put time and effort into opening an issue on a project. When the maintainer closes it without even taking 60 seconds to type a quick message why, it shows me that the maintainer is the entitled dick, not the user.
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.
When I see someone expects/demands something of me, I point them to the permissive MIT license. I am also a Spaniard living in Japan, so the concept of "social norms/expectations/etc" (whatever that even is) is totally meaningless to 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.
It sounds like you and I are in agreement then. This is the same way I manage my projects as well. I think this is the best way to handle it. It gives respect to others without accepting disrespect from them.
> I make a point to fix typos and such in documentation when I find them
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.
Maybe you know the OP, but in my experience a lot of issues are not bug reports but very low quality, uninformed or unreasonable requests or questions. Like questions made about basic functionality that is answered in the documentation/faq, or requests for features that are completely outside the scope of the project. Another popular category is requests for basic education e.g. “how does DQN work?”. That’s fine if it’s one person but when it’s 100 it gets overwhelming.
Exactly this. Bug reports were very welcome! While I stated that the API would not expand any longer in some projects, I also considered coherent feature requests a positive, and normally suggested and guided those as a plugin that lives within their codebase.
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.
Sure. On the other hand, sometimes people put a lot of time and effort into isolating an issue and writing up the best description they can manage. Closing the issue is a one-click FU to the people who are doing their best to help.
Some users are overly entitled, but some maintainers are self-absorbed douchebags. I've seen both sides.
I will never understand this point of view. The author has already given you possibly hundreds of hours of free labor simply by publishing the project. But now, because they won’t give you a few more, they’re a douchebag?
Even if they close all issues with no comment, they have given you a such _massive_ head start vs having to write the entire project yourself from scratch. How can you be anything but grateful?
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.
This a thousand times. If you hit a bug on my code and put together a PR to fix it, the reasons I would merge it are in order of importance:
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).
> It's just that if you put lot of effort into isolating a bug for someone for free, it can feels bad to have it rejected without explanation.
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.
> 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?
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.
I can understand this. I think once I realised that there was significant value to me in putting the bug report together in the first place, I felt happier if it just got closed or ignored.
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.
I've given thousands of hours on my open source, but just because it's the way I code. Any personal project where I create a small self-contained abstract unit, I'll put that as open source. Most of this code (by, say lines) is provided "as-is" with no much expectations. Those where I think they solve a real gap in the ecosystem I'll put more effort into writing good documentation.
If they have it open for issues and then handle the responses they have invited poorly, then yes, that's rude. A douchebag doesn't magically stop being a douchebag because they've open-sourced some code.
I've done this after scouring the documentation and being unable to find an answer. When there isn't a newsgroup or email list setup it's often really the only way to get in touch with a developer or maintainer. Suboptimal for sure, but if a library seems like it may solve your problem, it's worth a shot.
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.
At the risk of stereotyping a bit here (from personal experience), Wordpress users tend to be a lot less technical than C programmers, and I find the less technical the audience, the more entitled they tend to be. My theory is that because they don't sling code themselves, they just don't understand how much work and effort goes in to making good software. Because they don't understand it, they tend to not appreciate it.
I’m not sure it’s quite this simple. I maintain a popular video player and as such many of our users are nontechnical but some are more familiar with some of the options that are offered than I am myself. Whether someone is entitled really depends on…whether they’re just entitled in general, I think. I get people saying that we should “just add complicated xyz feature” who clearly don’t know the complexity involved, but then people with just as much experience leave issues like “I love your software so much but it is crashing every time I launch it (actually a one line fix, which they don’t know), can you please take a look at this, I’d really appreciate it” which is like the perfect issue. On the other hand I get technical issues with people filing pull requests to fix them but then sometimes I need to say something they won’t like such as “we don’t want this feature” or “we can’t work on this” and I’ll get a range of responses there too.
That’s exactly what I would do. It’s very similar to people asking you to fix their computer for free when you have tech skills. Ask money (even just 5€) and 90% of requests fade away. The one that remains are willing to pay (and more than a few bucks).
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.
Totally agree. I have 100+ repositories open sourced (Just launched this website yesterday! https://statux.dev/), a handful of them with 1k+ stars, and for the most part it's just me maintaining those.
This is besides my fulltime job, friends and hobbies. So I don't really have much time for growing a community, I've done some effort in the past when I had more time and it worked fairly well, but I found it to be very project-oriented in general so if you do many smaller projects (as opposed to few large ones) the community approach doesn't scale well.
I don't encounter many mean/crazy people! I can count them with one hand. I find few entitled people, but most people I've found are nice.
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.
Application domain may have something to do with it, language also. As a maintainer of Javascript and Ruby libraries, the difference in entitlement and cluelessness is remarkable.
This is encouraging to hear. My company built a tool to improve website accessibility. It fills a niche. We're almost ready to open source it. Basically just need to make the Github repo public.
The one thing that gives me pause is the prospect of having to manage a bunch of unfriendly feature requests and bug reports. Here's hoping we find ourselves in a virtuous niche.
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.
If you want to others use it, then document it. I really appreciate it. Otherwise, if you only wrote it for yourself you did enough. Undocumented code is better than no code. If you didn't publish at all I would have to start from zero.
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.
Though I love a good fatalistic Jamie Zawinski reference, I’ll resist and stay on-topic. I think you mean “for the kind of software I typically get paid to write, software is never finished.”
However, if you widen your perspective a bit, you’ll find plenty of examples. I assure you, “space invaders” was finished in 1978, and it will never see any “maintenance”.
I mean yeah, every piece of commercially available software got shipped at some point, and especially before the internet that software was mostly done being changed forever. That doesn't mean it was finished!
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.
Have you put some disclaimer about your situation and said that this repo won't be maintained and feel free to fork? I think it'll be the best resolution for your situation.
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.
Thanks for acknowledging this might be a language or cultural thing. I’m sure this kind of „smalltalk“ is appreciated when you put your free time into what others maybe use for their job.
One thing I would like to suggest is to have a question in the feature or bug issue template to ask what people use the lib for and what they like about it. Maybe even set expectations.
I see similar types of reactions to intra-team pull request comments. I think it's a facet of the facelessness of online comments.
I think there's a lot of scope for changing the way that comments on issue trackers and pull requests are taken in order to make the interactions more human and friendly.
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."
The first thing you learn when you're proud of your Github profile is that nobody is actually clicking into your projects and reading code, with few exceptions.
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.
I learnt this when I uploaded a project that claimed to do something but was only like 10% finished and you couldn’t run it.
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.
FWIW, stars on Github aren't means of expressing that you've tested and liked something; they're means of bookmarking interesting repos. So it's entirely plausible you got hundreds of stars and nobody ever run the project. Myself, I've stared close to 300 repos, and have run maybe a handful.
When I've interviewed developers, I will look at their profile if they include it in their resume, but only give it a cursory look, to maybe ask some high level questions in the interview. If I had a lot of time to do in-depth code reviews of projects that aren't my job, we wouldn't be needing to hire :-)
I got an internship at a big company simply because my project was in line with a project of theirs. Instead of being contacted by a recruiter it was an actual developer!
It's uncommon (and my anecdote is part of the "exceptions" for sure), but it's very very motivating when it happens.
Haha, admirable but I love employers like that. When they proactively remove themselves from the process without intervention from me we've made selection so much more efficient.
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.
Some employers may do that. But, from the github profiles I’ve looked at, I’ve found that writing an ok README file and any coherent inline documentation or comments would put you in the top 5% of job applicants. Even if the code itself is crap.
I have code posted that I'll use for CV that the README says 'will not work in Firefox'. Even though I'm using FireFox to post this comment, I don't care if Fx won't fix their 4yo RegEx bug. My project is meant to live in Cloudflare Workers, NodeJS & related things.
I do not ask to see candidates GitHub profiles, no.
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’ve evaluated GitHub profiles and contributions in the past. As long as there’s a body of work with reasonable complexity and no big red flags like a nasty argument or a bug-riddled PR, I consider it a positive signal that they can code. I specifically look at their opened issues and PR’s, rather than their commits, as a way to gauge their ability to code in a team setting.
I won’t try to guess how good they are at coding from GitHub alone. Most of my own public contributions are cases of “four days studying, two hours coding.” So as an exercise in tempering my interviewer ego, I remind myself that by just looking their work, I am very likely missing a lot of the picture.
I'm pretty cynical about how any code evaluation is done.
Amongst the many many ways code evaluations fail, the worst and most typical IMO is that the evaluator has an air of superiority, who marks down things they don't understand, and thinks their own coding is that of an artistic genius, approaches the tasks with zero science or rigor and is unable to articulate anything hard to back up their vague assertions coming out of the assessment "process".
I like giving a cursory glance at candidates github profiles mostly to see what they're interested in, if they participate in open source, things like that. The particular "quality" of code is imho relatively irrelevant.
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.
Honestly, since we hire everyone on as a contractor first, I generally tend to believe that they can code if it’s on their resume and they’re otherwise a decent person and able to work in a team.
If someone doesn’t work out we just let them go after half a year. So far that hasn’t actually been necessary.
How do you differentiate between "reasonable developer, can deal with complexity" and "extremely good developer, will dramatically improve the codebase and produce less technical debt"?
Does the distinction matter at your company, or is the primary metric "good enough"? Is this industry standard, or does it vary by company?
How do you differentiate between "reasonable developer, can deal with complexity" and "extremely good developer, will dramatically improve the codebase and produce less technical debt"?
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.
I'd start with the question of "why do you consider yourself significantly better?" Are you better at designing clean API's than your peers with the same number of years of experience? Are you a better writer/communicator? Do you have an unusual depth of experience with the end to end sales/design/implementation/support cycle? Or are you a really good coder who makes everyone around you better?
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.
When I find an open lib on github that looks to solve the problem I have, and it has a "warning! don't use" on it - I assume this means the author has no intention of maintaining the library, accepting patches, or preserving backwards compatibility.
Contrast this with the standard assumption - I'm using random code off the internet with a good faith effort by a maintainer not to break my stuff. If I find things broken, I may upstream a patch to said maintainer - or decide it's not for me and move on.
I never go through the latter effort when there is a big warning on the Readme.
Unless you have something specific to point out / warn users about, why? It is what it is, and unless users contribute something back to make it better, it's cost them nothing. If they did contribute something back, then hopefully it's a little less shitty. Unless the library in question is objectively bad and/or non-functional, no apologies or disclaimers are necessary.
I see nothing wrong with a disclaimer along the lines of "This is a hobby project. As the author I care about this project and want it to be as good as possible but don't expect the kind of polish you'd see in projects with corporate backings." It doesn't discredit the project in any capacity, it just tempers users expectations.
You'd assume so but as others have recently started posting in the comments on this thread, maintainers for small projects regularly get barraged with demands and spam/other forms of aggression in retaliation for not meeting said demands.
I'm not sure why but some people like to assume that just because you posted something online that you must fix any problem people have while using it and add any feature that it doesn't have. I suspect that this is the main reason those "This is a hobby. Please don't get mad at me if there's a problem" README tags started showing up.
Why not? Sticking a disclaimer saying "this has basically no test coverage" at the top of your readme has negligible cost and might stop someone from being fired.
Of course, there's no obligation or even expectation that you should provide such a warning, but if you're already thinking about it, might as well just do it.
At risk of sounding like a gatekeeper, maybe someone getting reprimanded for using an untested, production unready library isn't a bad thing.
It's not realistic to read through all the source of every dependency you use, but it should be encouraged for developers to take a more active approach in evaluating dependencies they pull in - at least to check how active development is, what sort of open issues there may be, test coverage, code quality sniff tests, what the license is etc.
I'd be willing to bet most GPL violations are due to ignorance, rather than intentional.
> a bit of a disclaimer in the readme should be expected
Every project already has these. They're in the license files.
> This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
This disclaimer is clear, self-explanatory, legally binding and a standard feature of all licenses. So why do people assume they can use random code from random developers they never met without even looking at the source code?
I don't think it's good to rely on the licence to carry this sort of information. Even if I have a library that I intend to maintain as polished and continually updated code, I'm going to have a licence disclaiming a legally-enforcible warranty.
And I might have a library that over the years changes from being shitty to high quality (and back!). I wouldn't want to go changing the licence to follow its lifecycle.
I think it would be valuable to have some widely understood conventions of text you can put in the README to set appropriate expectations.
Counterintuitively, absolute disclaimers of warranty aren't legally binding in many jurisdictions. So don't assume that you are legally absolved of any responsibility just in virtue of having this line in the license.
That us not how open source ever worked. You get high quality open source from established projects and stability from governance. By governance I mean something like apache or eclipse or linux foundation that forces projects to be lead in certain way.
Random code from random people always had varios quality - from great to horrible.
Tend to disagree w.r.t. the disclaimer tbh. Be it GitHub or package manager of choice I don't get where the default assumption became "everything on here is curated and production ready" rather than "this is something a 15yo built 5 years ago while on shrooms". That's part of due diligence, if I use something that isn't explicitly marked as maintained or don't understand the state it's in that's on me imho.
There's also different "shitty"'s. Some are only aesthetic/architecture features like bad CSS or a kooky object model or API or performance problems or something, but some have security vulnerabilities.
No — they’re useful for you (presumably) which is enough reason to keep them. But they’re useful documentation too. I’ll usually search for “todo” as part of evaluating a library because it highlights what’s missing as well as the developer’s priorities and mindset.
I don't in any of my open projects. They're there for a reason!
Many of them are written in a way that is probably useful to another coder who is taking the time to look at that piece of code — whether because of an issue, or for 'fun'.
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.
Start fixing typos in the docs and error messages in projects you use.
Try to send bug reports and look at how they fix it. Sometimes it is even difficult to find the file that must be fixed. Perhaps next time you spot a bug, it is in the same file and you can fix it.
Start with small changes, I recommend not investing more than one of two afternoons because the maintainer may not merge it. Perhaps because the code is bad, perhaps because it doesn't follow the (implicit hidden) spirit of the project, perhaps because the maintainer is a moron.
Try to follow the nearby code style. Each project/maintainer has preferences. If you break them, the maintainer may ask nicely to fix them before merging.
(If they are not nice, just forget about the project. You have lost only two afternoons.)
(Whitespace changes is a hot topic, try to avoid whitespace changes unless you know the local policy.)
> I know it isn’t “correct” (as in, idiomatic or ideally what you should write).
That's why there are maintainers who will tell you what you should change in order for your patch to be accepted upstream.
This happens all the time, just go and read the mailing list or active Pull Requests of the project. (This is a good idea anyway, as reading through pull requests and comments will give you a good idea how 'things are done' in that project)
And don't worry, most maintainers are usually very friendly to newcomers. :)
> but I’m just too embarrassed at the low quality/ugliness of my code.
If you contribute something to the Open Source community that works and is useful, then you might find some people who really appreciate the effort you went to.
The problem is that in practice there are many times that the visible different between "done" and "abandoned" is null, specially for smaller single-purpose libraries.
I’d disagree with point 2. There shouldn’t be any responsibility for a (ex-)maintainer to provide alternatives themselves; especially when there may not be any at point of abandonment .
Is there significant value to maintaining a set of glorified search engine results in a README? It means the list of alternatives then have to be maintained in case they too are abandoned.
I find the GitHub "archive repo" functionality a great, easy way to indicate a repo is abandoned; the most you need/have to do is a little readme edit/repo description edit if you want to explain or point to a good alternative.
"No longer maintained" is hard to define, does no commits in the last year mean "this project is mature and needs no changes", "this project is dead and should not be used" or "the author still cares about this project but is busy with other stuff this year" or something else?
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.
Glad to hear someone is picking up maintenance for this! I found it via Google a while ago and ended up forking it to make it play more nicely with Google Maps. I really appreciated the starting point though and that a lot of the heavy lifting of creating a custom model field had been done.
Right on. Please reply in the 'path forward' issue with a link to your fork. I'm interested in learning how people have taken upon themselves to improve the package.
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.")
> There is no obligation to free labour. Every hour you put in working on your project for free is a gift to the world. If the world comes back to you and says "You are a bad person for not supporting this thing I need you to support" then fuck them. If they want that they should pay you for it, or do it themselves.
I've had my Javascript canvas library "side project" on GitHub for seven years. In those 7 years I've had exactly ONE issue opened - which then got closed when the person who raised it worked out for themselves how to solve the problem they'd encountered.
Instead, people email me their questions - maybe a dozen of those over the years. They're usually really simple questions on how to do this or that using the library. I ask people to open an issue on GitHub for their question (because other people might find whatever answer I come up with useful) ... then I never hear from them again. I like to assume they solved the issue for themselves and don't need my help; others may choose to interpret the facts differently.
So I'd actually welcome people raising issues. It shows me that my "side project" is more than vanity, that people find it useful. And it would help improve the library because I can't think of every use-case or edge-case myself.
... But whatever happens, I'll still continue working on the library: some compulsions are beyond cure!
Thanks so much for saying this. Those thoughts hold me back when I'm thinking about starting an open source project. I already do lots of coding at work. I'm single and no kids, but spending a large amount of time on it in my free time would totally wreck my balance. I love coding but I also need non-technical activities in my life.
> I think of someone releasing open source software as a gift to the world, not as claiming a responsibility to maintain it for you. Some projects do claim that responsibility, but it’s not automatically conferred just because someone released a project on GitHub. I think much more of the responsibility falls on the person using it.
The nice thing about your shitty code is that it's yours and you don't have to open source it if you don't want to.
However, we live in such paranoid times, that if you do release a project and don't open source it, people will immediately convince themselves and others that you've bundled malware
in it. It's a sad state of affairs.
Code well, or code badly, Open Source or don't. It's your life, do it your way.
It's a matter of expectations. I believe expectations are extremely important when releasing anything creative, be it code or art or writing.
You might release something as a side project of a hobby, but people will become angry with you if it doesn't do what's advertised. This is significantly amplified if you go out of your way to tell people the project exists, in the hopes of it becoming popular and used. It can't become popular if it isn't good enough. That's the same for many different disciplines and various subjective standards of "good." In the case of software correctness is often stressed, unless it's generative art or something. So by marketing something in the hopes of it becoming popular you obligate yourself to getting it to the point where it can become popular.
So it's about not looking arrogant by saying something is true about a project when it isn't.
The problem isn't as simple as "don't mind if it's bad." Your library could end up being used in hundreds of projects. People want continued maintenance in this case. They might start filing issues against your project because of unforseen downstream bugs. But you might not feel like maintaining it anymore. Motivations change. But you'd have to be careful if you choose to hand off maintenance, because this can happen: https://github.com/dominictarr/event-stream/issues/116
So it isn't just a case of whether or not the code itself is bad. It's also about how you market the code to others. Ward people away if it's not production-ready. Sometimes undersell and never oversell. Remove any reason for people's expectations to be out of sync with the actual quality. In the case of event-stream the old maintainer became relied upon and then made the incorrect decision of letting an untrustworthy person have access to the code.
And also make clear your motivations. The creator of uBlock Origin states he might get bored of the project and move on. Give yourself an escape hatch like this so you can excuse yourself if you believe you really can't find yourself with the will to keep working on it in the future.
As long as those expectations are very clear to anyone who uses your code, then it is okay for public code to be bad.
Reminds me of that rust developer who wrote a super-fast webserver... and was trashed by the rust community for not upholding their standards.
When he finally had enough and said he was going to (IIRC) delete the project, suddenly people started being nice.
This is naive. If it's a bad library full of bugs, it's going to be garbage code. I'm not going to spend inordinate amounts of time & effort wrestling with shitty code to earn the right to say the library is bad. IMO that's not a good standard.
I wasn't saying you couldn't call it bad. But I will say demanding it not be bad would be stepping over a line.
If money ever changes hands with the author of that code, that's a different story. But if it's something free you just found, and you have never paid the author anything, then at most you can warn others to not waste their time. You are in no moral or legal position to demand anything.
Yes, it is OK. Any software is allowed to be shitty as long as it works. But then people always go out of their way to tell you how shitty it is. The type of immature dev people who hang about here on Hacker News TBH. I ignore the mails, the terrible opinions because there are people who love what I do, although underneath it is not perfect.
So, we like to have some clickbait on the front row? Ok. I have a few more.
PHP: it is OK to be a bit shitty.
Javascript: It is OK for your type system to be a bit shitty.
Javascript: It is OK for your semantic consistency to be a bit shitty.
Java: it is OK for you syntax to be a bit shitty.
Java: it is OK for your value semantic to be a bit shitty.
MongoDB: it is OK for your design decisions to be a bit shitty.
node_modules: it is OK to be totally shitty.
I 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.