Live data from Hacker News

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

jacobtomlinson.dev

101–110 of 173 posts

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

#101
post #89
post #52

Earlier quoted context omitted.

> It's best to conform to the contribution process described by the maintainer to avoid wasting their time as much as possible. It’s not their prerogative to waste my time, just as it’s not mine to waste theirs. If they’re not happy with a PR they’re welcome to reject it, ask me to fix it, or completely ignore it. When they make a project public they’re explicitly condoning the fact they may get a PR (and nothing els…

> When they make a project public they’re explicitly condoning the fact they may get a PR I don't think that's true. It appears you just assume that because pull requests cannot be disabled on GitHub. Sending unsolicited pull requests to people that clearly told you to open an issue first is disrespectful. You don't have to engage with a project or a community, but if you decide to participate by submitting a pull re…

[deleted]

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

#102
post #52
post #49

Earlier quoted context omitted.

Your quick PR becomes the maintainer's burden, and rejecting a pull request can also come with a substantial time cost. It's best to conform to the contribution process described by the maintainer to avoid wasting their time as much as possible.

> It's best to conform to the contribution process described by the maintainer to avoid wasting their time as much as possible. It’s not their prerogative to waste my time, just as it’s not mine to waste theirs. If they’re not happy with a PR they’re welcome to reject it, ask me to fix it, or completely ignore it. When they make a project public they’re explicitly condoning the fact they may get a PR (and nothing els…

I assume the PR describes the thing you are fixing anyway? (It better if you want it to have a chance of getting reviewed/merged!)

I don't see why you couldn't just file an issue with the copy-paste of that description, and then immediately file the PR too with a proposed solution.

I don't understand this issue/dispute. I don't understand the problem with filing an Issue to correspond to the PR, it doesn't seem to be any significant extra work or change to the desired workflow of the person who "just" wants to file a PR.

Am I misunderstanding the issue?

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

#103
I feel like there is a lot of articles lately that call for empathy towards oh so ever poor and overworked and burned out maintainers. All true, but this is only half of an issue.

The issue is that the concept often brandished in those articles, empathy, is a two-way street. There are maintainers on one side of this, and there are, on the other hand, users, who often are integrating multiple software projects and products to produce a solution of some kind. Mind you, those users are not always entitled prima donnas at FAANGs making another service to track you or something inconsequential like an online game. Sometimes they are integrating stuff at your local ISP. Or it's some system at a local school. Or they are making systems that are just means to an end, like in a hospital, or a bakery, or whatnot. Or it's an automotive shop. You get the idea; the world doesn't run on cat pics alone, and sometimes a complex software system is just an ingredient.

And you know what? When integrating all this stuff, you end up not with that small insignificant bug in that one project, but with multiple bugs in many pieces of software that have all to work together and be reliable. You also deal with not so much bugs per se as impedance mismatches that you have to paper over. It really ends up bleeding from a thousand cuts.

"Fix it yourself" is possible, but it doesn't scale. Upstream doing it scales.

And before you tell me, "well if you're so upset then don't use it", or "nobody owes you anything so fuck you", I have to say that it works the other way too.

I get a feeling that many open source software maintainers get into this business because they think that either a big company is going to pay them dearly, or their résumé will be stellar, or that they will become rockstars and get all the bitches from it. And when harsh reality sinks in, they start writing about being overworked and burned out. Not every maintainer does it, but many do, or at least it looks like it.

And if you get burned out and whatnot, you have an option to just stop working on stuff that is deteriorating your health. Walk away. If a popular project is hinging on an unhealthy development model and is going to die if you walk away, so be it! The market will cope, believe you me. The community will find a way around it. What is not good, though, is if you, the maintainer, are burned out, or overworked, but stubbornly insist on being a bottleneck in the project under your inept stewardship nevertheless, and just whine and moan about your burnout to get internet points and worldwide pity.

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

#104

I feel like there is a lot of articles lately that call for empathy towards oh so ever poor and overworked and burned out maintainers. All true, but this is only half of an issue. The issue is that the concept often brandished in those articles, empathy, is a two-way street. There are maintainers on one side of this, and there are, on the other hand, users, who often are integrating multiple software projects and pro…

>What is not good, though, is if you, the maintainer, are burned out, or overworked, but stubbornly insist on being a bottleneck in the project under your inept stewardship nevertheless, and just whine and moan about your burnout to get internet points and worldwide pity.

The problem is when there are no other maintainers to the project, and you quite firmly believe the project itself has a future, just that nobody else is able to do so. Yes, you can quit, but if people truly do rely on your project (but nobody is actually willing to take the reigns) then it can become an issue of pride for some. To be clear, I'm not suggesting that people burn themselves out (I myself have gone down that road before), just that "Walk away" isn't always such an easy option for some people.

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

#106
post #26

Earlier quoted context omitted.

> This can be useful to maintainers because they can sort by thumb up and see the most popular ones. TIL, but I also think it's not really clear what a reaction does. Does adding a reaction to a comment in an issue thread bump the whole issue, does it have to be added to the top issue to show up in sorting? I think a global "Vote for this issue" button would make this a bit more clearer than just a reaction within th…

> Does adding a reaction to a comment in an issue thread bump the whole issue, does it have to be added to the top issue to show up in sorting? Yes it needs to be added to the top post. It's not really an official thing I guess, but for popular projects these reactions add up, and it helps getting a clearer picture of what matters to users.

It is "official" in the sense that GitHub lets you sort by these reactions.

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

#107
One thing I've done from time to time is just say "hey, I would like this a lot, I'd put a $100 bounty on it". Probably wouldn't work in the corporate case described here, and certainly is below the "actually paying for a developer's time" level.

But I've thrown a bonus in there for doing it. Maybe if it's already something they wanted to do, it moves the needle into "sure, let me give it a shot".

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

#108

I feel like there is a lot of articles lately that call for empathy towards oh so ever poor and overworked and burned out maintainers. All true, but this is only half of an issue. The issue is that the concept often brandished in those articles, empathy, is a two-way street. There are maintainers on one side of this, and there are, on the other hand, users, who often are integrating multiple software projects and pro…

>What is not good, though, is if you, the maintainer, are burned out, or overworked, but stubbornly insist on being a bottleneck in the project under your inept stewardship nevertheless, and just whine and moan about your burnout to get internet points and worldwide pity. The problem is when there are no other maintainers to the project, and you quite firmly believe the project itself has a future, just that nobody e…

> you quite firmly believe the project itself has a future, just that nobody else is able to do so.

Looks like some unwarranted feeling of self-importance combined with the sunk cost fallacy.

You still have options: make it paid only, stop taking contributions at all, hire someone to sort it out or find a volunteer to do so. Or walk away and see how quickly Amazon will copycat you.

Or accept that that’s the cost of having your pride.

Otherwise it’s almost a textbook example of emotional blackmailing some parents are known for.

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

#109
As a maintainer of a graph OSS project with an optional commercial tier, we are 100% fine with his original approach.

A clearly written issue or a +1 vote (not comment, which causes an alert) is definitely appreciated. We get to learn usage patterns to optimize, bugs to fix, etc, before they hit users in our paid tiers. Sometimes feedback isn't well thought out, so we added templates to steer users, and that worked pretty well. Various tricks like that have helped over time.

Likewise, when there is a commercial tier or outside funding, as in his case of Grafana, much less expectation of code giveback. Typically the maintainers have blown the path to open governance, and through that, significant OSS community It's freemium, and the interactions are more about issues vs PRs. Yes it's better when a true OSS community, not just license, but that's just not how most big ones work nowadays. So a helpful ticket is fine.

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

#110
post #78

> However I now see that my use of the tool provided no value to the company, and I was not a paying customer of any of their services, so why should they provide me with free support. That is not true. If the use of the tool provides "no value" to the company, then why on earth are they making the tool available. Yes, there is no money exchanging hands, but there is definitely some value. Here's some value a company…

We're decades into the open source era and people still need to be reminded of this. Incredible.
Post reply on HN