Live data from Hacker News

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

jacobtomlinson.dev

11–20 of 173 posts

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

#11
post #6

This is a thoughtful and important article for anyone who uses or creates open-source software, which is everyone. But, if we follow this advice? If some more thoughtful and considerate users kindly reduce their input into support conversations to avoid overwhelming developers, doesn't this mean that support conversations will become dominated by users who are not thoughtful and considerate?

The point is not reducing input per se, but reducing entitled input that doesn't give back anything to the community.

It’s a problem everywhere in software, the ones who give back the least feel the most entitled. Having a some form of a treshold is good, whether that is money, or some sort of on-boarding (e.g. can’t comment until you are a member for x days)

Usually the ones with loudest mouths have the shortest attention span and don’t bother with those things. I have seen this in many communities.

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

#12
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 guess the "be excellent to each other" note at the end of the post is basically be polite. Often there is a reason why simple request take time. It can be hard to describe why.

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

#13
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 they tied it to funding, which helps with project viability but introduces a prioritisation bias towards people who have money to donate.

https://www.igalia.com/open-prioritization/

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

#14

I can partially agree but we live in a day and age where asking someone their name may be considered offensive. I think there is a lot more value in teaching people self-worth and to not be so easily offended by people asking questions and then they run sway and hide and say that you hurt their feelings by asking them. A simple disclaimer that says they don't have any obligation, or heck most open source licenses ind…

This goes both ways. It's also fine to ignore your open source users, or refuse their requests. What will they do, fire you? Stop paying you? If they don't like it, it's on them.

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

#15
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 think when an issue becomes highly ranked by users, it’s important that devs give clear feedback. In communication, acknowledgement is very important. Just say it if it’s not on the current to do list and when you project to be working on it (or not at all)

It gives a clear feedback, and allow people to move on, fork it, stick with it, their choice. Politeness should be key.

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

#16
post #13
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…

Doesn’t monetization also indirectly help the other issues?

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

#17
post #6

This is a thoughtful and important article for anyone who uses or creates open-source software, which is everyone. But, if we follow this advice? If some more thoughtful and considerate users kindly reduce their input into support conversations to avoid overwhelming developers, doesn't this mean that support conversations will become dominated by users who are not thoughtful and considerate?

The point is not reducing input per se, but reducing entitled input that doesn't give back anything to the community.

>The point is not reducing input per se, but reducing entitled input that doesn't give back anything to the community

That's true, and it's a good goal.

But, my point is that if we try to reduce entitled input by simply asking people not to behave entitled, then the result may be that we increase entitled input (as a proportion of all input), because many 'entitled' users will ignore the request, because they feel entitled.

In the common scenario where developers are already overwhelmed with suggestions and demands, then they will have even less time to separate out the good suggestions from the bad.

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

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

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

#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?

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

#20

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?

The word you are looking for is consumers' co-operative (https://en.wikipedia.org/wiki/Consumers%27_co-operative).
Post reply on HN