Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't be that open-source user, don't be me

jacobtomlinson.dev

Post reply on HN
Print view View original

91–100 of 173 posts

Re: Don't be that open-source user, don't be me

#91

Post by lifeisstillgood »

UncleEntity wrote: post #86
lifeisstillgood wrote: post #19

Just a thought (vaguely connected here) but voting on features to be implemented is ... pretty much same as voting IRL on policies not parties. I have often wondered what would be the thing to trigger companies to stop being totalitarian dictatorships and become democratic to their (employees / stakeholders) - is it crazy to say voting on features to build would be the one?

Unless you have an absolute monopoly market position you are a democratic institution where the ‘votes’ are people giving you their hard earned money in exchange for whatever you’re selling. Where things go wrong is ‘stakeholders’ (aka non-paying people/customers) demanding influence for whatever is important to them like savings baby seals or whatever. They know they can’t influence the company by ‘voting with their…

Oh there are so many ways to play this game - kickstarter is basically voting in advanace with your money.

Re: Don't be that open-source user, don't be me

#92

Post by vegetablepotpie »

strken wrote: post #66
mid-kid wrote: post #48

Earlier quoted context omitted.

> The worst they can do is reject your changes, in which case...well, you're using your fork anyway. Actually the worst result is ignoring the PR for years. I've seen this happen quite a lot, and it puts me in an uneasy spot where I don't know whether it's something with the PR or the way I communicated it or what. After having this experience one too many times, I've started opening issues and if I'm really serious…

It doesn't matter if they ignore the PR. You've got a working fork. Merging your changes back into the upstream is a happy side effect.

We’ll, maybe. It depends on what kind of project it is. What happens when your fork introduces hard to reproduce bugs? What happens when there are security updates to the project that cause merge conflicts with your fork? What happens when the project makes architectural changes that require reimplementing your feature? What happens when you leave the company, and your former coworkers have the responsibility to maintain your fork?

Re: Don't be that open-source user, don't be me

#93

Post by throwaway0129u »

davedx wrote: post #40

Counterpoint: you have a successful open source project and you even “branded and marketed” it (like Grafana). You obviously want it to be successful? Then listen to your users and respond to their questions . Entitlement is a two way street.

True.

If someone clearly describes their project as an experiment or a hobby project then no responsibility should be attached to it.

But if they advertise it as something production-ready or secure they are capturing user's trust, attention and time.

Some company-driven projects even use open source as a foot in the door to get user's data or corner a market and charge money later on.

As a developer your time is valuable and users should not be demand it.

As a user your trust, attention and time are valuable and not every random project on github should get it.

Re: Don't be that open-source user, don't be me

#94

Post by layer8 »

I see this a bit more nuanced. On the one hand I believe it’s important that users communicate what they’d like the software to be, and also when they are frustrated about a lack of progress, but on the other hand they shouldn’t act like entitled assholes about it and/or constantly complain about the same thing over and over again. It’s possible to express dissatisfaction with the software while still being respectful towards the maintainers. And the number of “me too”s (+1) can be useful information.

With regard to time and attention, that’s more a matter of tooling and push vs. pull. As a maintainer, I’m responsible to not let my time and attention be strained too much, just as with any other communication. For example, by auto-filtering issue tracker notifications into a dedicated folder and only looking into it at scheduled, time-boxed intervals.

Re: Don't be that open-source user, don't be me

#95

Post by UncleEntity »

rurban wrote: post #82

Looks more like the new US youngsters becoming more like brainwashed Chinese or Russian apostates, who need to make public apologies before being allowed into society again. mea culpa, mea maxima culpa. What's wrong with you? Seriously. There's nothing wrong in these tickets to apologize for. Issues are for public discussions of issues. If maintainers cannot deal with public issues, they cannot be maintainers. Proble…

So… guessing you have never contributed to an open source project in any meaningful fashion?

I somewhat agree with you though, try to work on a project that has artists as the primary users sometime if you really want to see entitlement. Not that I have anything against artists in general but they usually have no clue how much work goes into their “simple” feature request from a demo video they saw from siggraph and now they absolutely have to have or they will quit using the free software — after completely spamming the mailing list and bug tracker to get other users behind this must have feature to show the devs how important it is to implement.

Makes me kind of miss working on that program.

—edit—

And there were the occasional rewrite it in Java people, now they were really fun. There was one who actually machine translated the entire C codebase into Java and wanted the whole project to fork on that. Loved the Java ones.

Re: Don't be that open-source user, don't be me

#96

Post by vegetablepotpie »

Reminds me of the wiring pi debacle. Gordon got tired of supporting novice users for free and stopped publishing updates to his project in 2019.

> I’ve had over 10,000 emails from people who upgraded their Pi and found that code stopped working because they were reliant on a system, which had statically linked an older version. This sheer incompetence on their part has saddened and depressed me hugely.

https://www.i-programmer.info/news/136-open-source/13036-wir...

Re: Don't be that open-source user, don't be me

#97

Post by kayodelycaon »

pcthrowaway wrote: post #39
laurent123456 wrote: post #8

Regarding adding +1 to issues - rather than doing this, up-vote the issue on GitHub (thumb up). This can be useful to maintainers because they can sort by thumb up and see the most popular ones. Adding a +1 comment really does nothing - it's just one more useless notifications for everyone, and it won't allow filtering or sorting issues. People might even unwatch the issue because of this and thus missing useful comm…

Perhaps I misunderstood the author, I assumed '+1' in this context meant the thumbs-up reaction. I'm certainly feeling much more charitable towards the OP if they literally meant people commenting "+1" (which is unfortunately a thing), but I think in a lot of contexts "+1", "thumbs-up", "like" are interchangable.

It’s literally people commenting. There’s a subset of users that haven’t noticed or haven’t understood the reaction buttons.

Re: Don't be that open-source user, don't be me

#98

Post by [deleted] »

jlkuester7 wrote: post #84
MereInterest wrote: post #70

Earlier quoted context omitted.

I've never really understood the point of these bots. I could understand if an issue had a test case attached to it, and the bot was auto-closing the issue if/when the test passes. That way, if it is resolved when fixing some other bug, or when refactoring, the issue is closed. But closing an issue due to inactivity gives the false impression that the issue has been resolved.

Same, I find these bots really annoying. I guess they might be necessary/useful for popular projects where a small team of maintainers is trying to stay on top of a massive pile of incoming issues. But for the most part they seem misguided. (Especially the ones with a really short (like 30 days) activity window.) If an issue still exists in the project, why should it be closed? That will just require the next person…

[deleted]

Re: Don't be that open-source user, don't be me

#99

Post by yorwba »

johannes1234321 wrote: post #83
MereInterest wrote: post #70

Earlier quoted context omitted.

I've never really understood the point of these bots. I could understand if an issue had a test case attached to it, and the bot was auto-closing the issue if/when the test passes. That way, if it is resolved when fixing some other bug, or when refactoring, the issue is closed. But closing an issue due to inactivity gives the false impression that the issue has been resolved.

It depends a bit in the project and maintainers motivation. However: Many projects swim in a sea of open tickets. Too many for the maintainers to keep an overview. By auto closing you make it clear to observers that currently this thing likely won't change and by forcing to reopen the maintainers can get users to tell them whether the issue still persists without having to try themselves. Generally there is little wo…

How do old tickets hide recent issues? The default is to show the newest ones first, isn't it?

Re: Don't be that open-source user, don't be me

#100

Post by jrochkind1 »

MereInterest wrote: post #70
droidist2 wrote: post #55

Earlier quoted context omitted.

Then again, adding a comment may prevent a bot from auto-closing the issue.

I've never really understood the point of these bots. I could understand if an issue had a test case attached to it, and the bot was auto-closing the issue if/when the test passes. That way, if it is resolved when fixing some other bug, or when refactoring, the issue is closed. But closing an issue due to inactivity gives the false impression that the issue has been resolved.

I think they are basically an attempt at form of "issues/tracker bankruptcy" -- we have too many open things here, leaving them all open like we're going to get to them all eventually is a fantasy, and is overwhelming and makes it harder to find the ones we might actually address, so trying to algorithmically close the ones least likely to be actionable is just trying to make the situation more manageable.

I think it's a desperate measure -- if any maintainers are seeing it as reasonable management technique rather than desparate measure, I think they're making a mistake. It has a lot of downsides, some of which you outline, I agree with you. It also generally raises user frustration, leading to even more adversorial relationship between users and maintainers, which is what the OP is about and I think part of what's going on in this "issue bankruptcy" situations too.

Notably, Rails just turned off their auto-closer for Pull Requests (not sure about Issues), with this commit message from a maintainer:

> While the idea of cleaning up the the PRs list by nudging reviewers with the stale message and closing PRs that didn't got a review in time cloud work for the maintainers, in practice it discourages contributors to submit contributions.

> Keeping PRs open and not providing feedback also doesn't help with contributors motivation, so while I'm disabling this feature of the bot we still need to come up with a process that will help us to keep the number of PRs in check, but celebrate the work contributors already did instead of ignoring it, or dismissing in the form of a "stale" alerts, and automatically closing PRs.

https://github.com/rails/rails/commit/acf48169943011834c4c88...

Post reply on HN