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

61–70 of 173 posts

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

#61

Post by tommoor »

politelemon wrote: post #21
bambax wrote: post #18

> If you were to develop a closed source iOS app and charge for it in the Apple App Store your user base will have certain expectations. What's weird is that paying users have lower expectations and are much nicer than those who don't pay. Why do free users feel entitled? It's a bit of a mystery, yet can be observed often.

This is not my observation at all. I encounter the exact opposite with paying users, and much prefer interactions with free users who are very understanding and empathetic.

free - medium support

$1 - high support

$100,000 – low support (after the initial deal)

Choose which you want to build :)

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

#62

Post by dom96 »

bsder wrote: post #10

I kinda blame Github for all this. In the past, there was just a bit of friction before filing a bug or dropping a comment on a project. You had to sign up for bugzilla. You had to sign up for the mailing list. Something. Anything. It was just enough friction that you had to want to post that comment or file that bug. You weren't going to waste your time just to be a shit. With everything on Github, it's simply too e…

This is actually a fair point and shouldn't be getting downvotes. Github has decreased the barrier to entry and sadly that has its disadvantages.

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

#63

Post by _8j50 »

kevincox wrote: post #58
_8j50 wrote: post #53

Don't be entitled but at the same time nothing wrong with respectfully asking for support. User support is the whole point of maintainance. Replying to issues to add "weight" allows maintainers to prioritize fixes.

I think asking for support is fine unless it is against the project guidelines. I think reporting bugs is almost always great. But I think that few if any projects and maintainers appreciate adding just "weight" in a comment. These comments just add load to whatever channel the maintainer uses to follow these things. If the comment has more valuable, like explaining a new use case that is affected by the issue then I…

Mostly agree, but personally I comment when it is a bug impacting production stuff(outage for me). I don't know how else to get support, if they have a paid support option my company would be all over it for most of these projects. But therein lies the usability issue of OSS. With commercial software I can open a ticket and at least get some response that will help me make plans on how to deal with the issue.

There really needs to be some org that simply lets devs get paid for supporting paying customers and let customers procure such support.

For personal stuff I don't care but after fighting many battles to sell OSS when I have some issue what other recourse do I have than to politely explain my situation and hope I get therir attention. I literally beg for help! I am sorry if that annoys devs, but it is either that or I give up on OSS and be permanently pessimistic about anything related to it.

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

#64

Post by 2Gkashmiri »

pabs3 wrote: post #13
welder wrote: 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…

Prioritisation often becomes harder the closer you become to being an open source maintainer, since you're often more focused on software maintenance/internals than on using the software in real-life contexts. I feel like creating systems for open prioritisation is going to be an important "next step" in open source project management. Igalia did an experiment in open prioritisation in web browser development, but th…

>Prioritisation often becomes harder the closer you become to being an open source maintainer, since you're often more focused on software maintenance/internals than on using the software in real-life contexts

i contribute to a FOSS project. I am not a dev nor can i hire someone to do dev work so i assist the actual dev team into giving them real life use cases which brings out a lot of bugs which get fixed along the way.

That way, instead of trying to achieve some sort of tangent "idea" of what a software is going to be and it becomes something the users can actually use and relate to.

the software in question, when people are going to use it and will face "normal workflow bugs" for example, we can forget about adding new features. right? maybe they can go side by side but unless you are working on the bleeding edge software and do not expect anyone to use in production it can work but not otherwise.

Also, by pointing out edge cases, the present software itself would become what would be called "battle tested" because most if not all the issues are fixed.

that said, if a project had a good budget, a good roadmap, a thriving developer community and users who are using it, reporting bugs and people volunteering to fix stuff, we can think about experimenting but otherwise not

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

#65

Post by strken »

dessant wrote: post #49
strken wrote: post #31

Sometimes you can just go fix the software yourself. Maintainers always seem to say you should file an issue before working on a PR. However, I find for features you really need, you should just fork the software yourself[0] and implement what you need, then put up a quick PR with your changes. The worst they can do is reject your changes, in which case...well, you're using your fork anyway. [0] Github forks are ligh…

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.

The best thing is to fork it, use your fork, get as far as you can through their process, but give up quickly if it looks too hard. That way you don't have to deal with overly complicated processes and you still get to use working software.

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

#66

Post by strken »

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

Sometimes you can just go fix the software yourself. Maintainers always seem to say you should file an issue before working on a PR. However, I find for features you really need, you should just fork the software yourself[0] and implement what you need, then put up a quick PR with your changes. The worst they can do is reject your changes, in which case...well, you're using your fork anyway. [0] Github forks are ligh…

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

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

#67

Post by svrtknst »

Something I believe is overlooked that is relevant here is the effect of large volumes of feedback, even positive. Sara Chipps wrote about it in her blog post on Stack Overflow[1].

I don't believe we as people are desgined to handle feedback and opinions from a large number of people, and it's very easy for even neutral or benign questions ("is this planned for a release?", "any news on this?") to become grating.

Kinda similar to when kids go "Mom, mom, mom, mom" - nothing harmful is being said, but the cumulative effect is exhausting.

IMO it's a good idea to question, has someone else asked this? has someone else already stated this opinion? before posting on forums.

1. https://stackoverflow.blog/2019/07/18/building-community-inc...

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

#68

Post by dom96 »

Thank you to the author for writing this.

Entitlement in open source is a massive problem, I have experienced it first-hand many times. The problem is that it discourages contributions not only from the existing maintainers but also from people who may volunteer to fix issues in the future. Would you be willing to contribute if most of the issues are just asking for things (often rudely) and not even saying thanks when an issue is resolved?

Unfortunately I have seen far worse examples than the one linked in the article[1]. I would encourage people to not only think twice before acting this way but to also call out people that are acting entitled in open source to discourage such actions.

1 - https://github.com/dom96/httpbeast/pull/35#issuecomment-7218...

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

#69

Post by projektfu »

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.

This jumped out at me. Software has always had grandiose marketing and I figure that a successful large-business image usually works better than mom & pop imagery. But it probably encourages people to see the person or team behind an OSS product as at least a cog in a big machine, if not a successful entrepreneur.

I'm reminded of the scene in Cinderella Man where Jim's wife Mae goes to tell off Joe Gould calling him rich and entitled, basically, and they invite her into the big apartment and they've sold all the furniture except a table and two chairs.

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

#70

Post by MereInterest »

droidist2 wrote: post #55
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…

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.
Post reply on HN