Live data from Hacker News

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

jacobtomlinson.dev

111–120 of 173 posts

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

#111
My general advice on this is to never rely on other people reading your mind. It's a path to frustration for you and the other people.

In this article I see a lot of phrases where OP is hoping other people share the same perspective. Like, "Hopefully we agree that...", "I want to argue here...", "Users... shouldn’t expect..."

It's just not going to happen like that automatically, though.

I suggest that if, as an open source author, you're seeing seeing potential for broad usage of your project, spend some time to think about what you're willing (and able) to give, and make an explicit statement to that effect (and put it somewhere that potential new users will see it).

I suggest that if you're considering using an open source project in something, spend a few minutes to think about what you will do if you get no more support than what is explicitly promised and/or paid for (which means no support in most cases). If that's not acceptable for your project, then don't use it.

(Oh, and sadly, I think this the purpose of this article is a bit hopeless. I think there are thoughtful people that will read this and take it to heart, but those people are probably only causing a tiny fraction of the unpleasantness that open source maintainers experience.)

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

#112

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

> we added templates to steer users

I think this is great.

Often, by the time someone gets to the point of figuring out how to comment at all, they have a real need and are more than willing to spend some time... but they have no idea what would help and you end up with an annoying demand or "+1" comment. A template directs the energy on a useful path (and implicitly balances/settles things a little bit... the user has to stop, think, and contribute a little bit back and a maintainer hears it in response)

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

#113
post #5

As an open source maintainer[1], the etiquette tips are great. However, I think +1 and status check comments are ok in certain situations where the issue might have been forgotten or it's a high priority issue. I also like when someone reminds me they're blocked by an issue. It helps me prioritize fixing bugs so I work on things actually affecting people instead of things nobody is using. Just be polite and your comm…

I'm not so sure +1's or emojis are useful, except for maybe a few cases like you have a very large audience and they all send a thumbs-down emoji to protest a bad product or design decision -- recent c#/dotnet for example. Or the reminder ping from an affected user who is still interested in and using your project.

The problem I believe is that a +1 or another reaction to an issue is simply a sample from all developers that viewed the project that bothered to leave a note. Chances are people are not using an open source project if they see a reasonably filed issue a long time ago that either was not addressed in any fashion whether it be a principled statement on why it can't be addressed yet, or that the project isn't interested in working on it. That obviously only works for small projects without a product manager.

The issue persists on the large projects as well. The issue reactions set is just a sample of the all developers set that used or looked at the project. The only way to really know what is going on is telemetry and crash reports.

Larger companies with thousands of crash reports, bug reports, and features requests can cluster them and figure out what to work on, along with a touch of good taste. Good taste is unfortunately important too.

Unfortunately for telemetry a lot of people think it is a privacy issue... which it can be if the developer implements it poorly. And looks like GitHub only exposes traffic overall to your site [1] so you never know the population size is for people that are possibly affected by that issue -- so the relative +1 count is not reflective of reality. You might have a fighting chance if you use self-hosted GitLab or something with which you can grab granular traffic stats.

[1] https://docs.github.com/en/repositories/viewing-activity-and...

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

#114

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…

I'm pretty sure that as a society we realised a very long time ago that for things that matter, tying votes to money is a really bad idea.

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

#115
Rude and entitled behavior is of course unacceptable. That said I think the project developers and maintainers often share a large portion of the blame. Most projects are very keen on telling you about their amazing new features and the awesome stuff you can build with it. What they don't do is properly document limitations of their software or honest comparisons with competing solutions. Additionally many developers overhype the status of their project. They'll call it production ready, mature, claim it has a vibrant community and ecosystem and so on, when these things really bend the truth. That builds expectations and running into critical, well known bugs that don't get fixed can be extremely frustrating.

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

#116
post #85
post #75

Earlier quoted context omitted.

I’m not sure what you mean by this example. From what I see, somebody submitted a bug fix that hadn’t been approved/merged by you for 6 months. Then some quite rude conversation happened “Don’t act as my free time is owned by you”. I mean both sides look quite ugly in this particular case to be honest.

> From what I see, somebody submitted a bug fix that hadn’t been approved/merged by you for 6 months. From my perspective the PR was reviewed and was stuck on a test case being created. The author of the PR even stated "I'll try to make a simple test case." so as far as I'm concerned the ball was in their court. But you know, reviewing PRs takes time too. Acting entitled about a review taking a long time shouldn't be…

> But you know, reviewing PRs takes time too.

I agree. I’m just saying you were rude too.

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

#117
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…

> Sending unsolicited pull requests to people that clearly told you to open an issue first is disrespectful.

You do you. I do not think it is, and so far nobody has made an issue out of it.

> It appears you just assume that because pull requests cannot be disabled on GitHub.

It’s more that people that make a public repo on Github and expect no pull requests on even mildly popular software are living in fairyland. Don’t make a repo on Github when you know PR’s can’t be disabled. Or I dunno, install a bot that automatically rejects everything.

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

#118
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…

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…

> I don't understand the problem with filing an Issue to correspond to the PR

I positively detest pointless bureaucracy?

I can live with it when someone is paying me 200k/year for it. Not when I’m trying to give my work away for free.

I’m honestly a bit surprised about how strongly I feel about this.

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

#119

Rude and entitled behavior is of course unacceptable. That said I think the project developers and maintainers often share a large portion of the blame. Most projects are very keen on telling you about their amazing new features and the awesome stuff you can build with it. What they don't do is properly document limitations of their software or honest comparisons with competing solutions. Additionally many developers…

My solution to this problem is to avoid libraries and projects that have one of those darkmode Web 3.0 scrolling pages as home that tell you in countless ways with lots of graphics why their project is so great. They usually aren't, and they are nearly always unfinished. In contrast, I've never had any problems with libraries whose home page is text only + links generated from Emacs org mode.

Good programmers don't waste their time making fancy web pages.

Post reply on HN