this post was submitted on 20 Feb 2024
1124 points (97.1% liked)

Microblog Memes

5837 readers
1668 users here now

A place to share screenshots of Microblog posts, whether from Mastodon, tumblr, ~~Twitter~~ X, KBin, Threads or elsewhere.

Created as an evolution of White People Twitter and other tweet-capture subreddits.

Rules:

  1. Please put at least one word relevant to the post in the post title.
  2. Be nice.
  3. No advertising, brand promotion or guerilla marketing.
  4. Posters are encouraged to link to the toot or tweet etc in the description of posts.

Related communities:

founded 1 year ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 5 points 9 months ago (1 children)

The more effort a user has to put in to use a tool, especially when other, easier and functional tools exist, the less likely that user is going to adopt that tool as part of their daily use.

The catch here is that oftentimes, for the use cases that people get elitist about, there are no other, easier, or functional tools, which is part of why it's so frustrating to encounter elitist mindsets around this stuff. I don't even really particularly care about not having .exes or what have you, or having to compile a python script, right, I mostly just kind of find it frustrating when documentation for these kinds of projects is extremely lacking and unclear as to what you're supposed to do. Shit takes 3 minutes on the dev's side, to curb like 20 or so more questions clogging up issue reporting and, realistically, what should be the avenues of contact you're gonna want to be using for bug reports. It's literally worse for the dev not to at the very least make the documentation a little better than it usually is. Sometimes that scales up to even be, it would be better for the dev to actually make an exe because that would be more idiot proof, and they would also get less shitty complaints.

Basically the argument I'm making is that many devs kind of encounter a deadlock where they get really frustrated at giving out something for free, then encountering complaints about inaccessibility, and then they start fighting ghosts when people ask them questions in lacking documentation. Most of these cases, if they'd put in slightly more effort from the start, they would've solved themselves a more massive headache in the long run. Lots of these, you don't even really have to put in a ton of extra effort, such is the upside of open source, you can just solve the documentation afterwards when someone comes in with a question the first time and then you take that feedback and actually append it to your documentation instead of just getting frustrated that everyone else is too stupid.

[–] [email protected] 0 points 9 months ago (1 children)

I'm glad to finally see someone in this thread talking rationally about this. Thank you.

many devs kind of encounter a deadlock where they get really frustrated at giving out something for free,

I get that, the world is expensive, but being profit motivated does not align with the open source ethos. I have no problems with devs choosing to go closed source and charging for their products, but 90% of open source projects never get to the point of being solid enough to be a paid product regarding ease of install and use.

[–] [email protected] 3 points 9 months ago (1 children)

I think it's less that they want to be paid, and more that they just are doing something that they think is kind of like, an altruistic act (and it is, probably, as long as they're not maybe encouraging stagnation or inhabiting the space so that another dev won't take a crack at it). So it's frustrating to be doing this altruistic, somewhat thankless act, and then get bitched at for it, even if you're getting bitched at because of your own stupidity, or lack of forethought, or insular presumption that everyone else knows how to do what you do. I empathize with them, and I see their problem, but I also understand why people are bitching, instead of just being like "the people who are bitching suck and are wrong" how people tend to do, which just leads to a positive feedback loop where everyone is constantly pissed off.

[–] [email protected] 2 points 9 months ago (1 children)

Look I did helpdesk for a decade, I know for a fact what it feels like to be bitched at by people that you try to help. What I'm saying is that open source projects need big teams and people who know how to organize them, and there should be a foundation with the sole purpose of rounding up donations to fund those teams working on worthwhile projects.

And if some exist now point me in their direction and I will gladly donate.

If It takes me less than 10 mins to install their software.

[–] [email protected] 1 points 9 months ago

I don't disagree with any of that, and I don't find it at all to be, generally, disagreeable, I don't think many would really disagree with that. I would maybe have some thoughts on the efficacy of different types of organizations, like, do we run this as a no-profit, or as a co-op that kind of absorbs multiple different open source projects into itself? I could see it working for sure, to the point where something like that has to exist I would think, but implementation details would make or break the motherfucker for sure. Also interesting would be how you figure out which projects to fund, compared to which you don't really give a shit about.

I was saying more, that I think the people who are disagreeing with you, are disagreeing from the perspective that everyone who makes demands of devs are entitled, especially when the devs are free. I don't really agree with that position necessarily, I was just trying to spell out that I think that's their position, more than that they necessarily disagree that open source should be, basically along your idea, better than it is. Better organized, more centralized, more easily funded, I don't think they're disagreeing with that, I just think they're more doing that kind of basic redditor shit where they want to argue who's at fault more, instead of recognizing the external circumstances which brought about the problem.