Live data from Hacker News

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

drmaciver.com

171–180 of 364 posts

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

#171

Earlier quoted context omitted.

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.

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

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

#173
post #106

Earlier quoted context omitted.

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.

> I'm not into js at all Programming in JS is just this way. I had to include moment.js yesterday just to format a date. Nothing fancy, but no easy way around it.

I'm not sure this is a good example; dates are actually pretty complicated.

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

#174

Earlier quoted context omitted.

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…

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.

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

#175
post #60

Earlier quoted context omitted.

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 i…

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?

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

#176

Earlier quoted context omitted.

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 entitlem…

Did you tell them why you were closing the issues as #WONTFIX? I maintain a few projects in the "hundreds of stars" range, and I also send PRs to numerous projects with regularity (I make a point to fix typos and such in documentation when I find them). 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 takin…

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

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

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

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

#178

Earlier quoted context omitted.

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?

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.

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.

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

#179
post #105

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 unde…

At scale, how do you tell the difference between software which is finished vs software which is unmaintained?

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

#180

Earlier quoted context omitted.

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.

If anyone is in any doubt about this, I would like to point them towards this github issue: https://github.com/mrc-ide/covid-sim/issues/165
Post reply on HN