3 ms·
To me a lot of OSS already has a disdain for the "lowest common denominator" type of users, and this article has this vibe. You don't have to "growth hack" and
by pornel 5y ago
To me a lot of OSS already has a disdain for the "lowest common denominator" type of users, and this article has this vibe.
You don't have to "growth hack" and beat $1T companies, but don't use that as an excuse for ignoring usability. In OSS "simple" more often means "works for the maintainer" rather than something that's actually intuitive and usable for the majority of people. If you only have a handful of hardcore users, because everyone else failed to run the software, and was told to read the (barely existing) manual, that's a problem with the software's design, not scale.
- spinningslate 5y agoGuardedly agree, though there's also entitlement risk here. If an author scratches their own itch, and it does what they wanted, and they decide to open source it, then good on them. Choosing to do so doesn't create any requirement to make it useful to anyone else. This is the root of a chunk of angst today: consumer X finds open source project Y, discovers it doesn't do Z, and throws a twitter/issue hissy fit. There's *zero* requirement on the author to fix the perceived deficiency, nor should there be any expectation. If X wants it addressed, then - as noted elsewhere in this topic - a founding principle of open source is that X is free to fork and fix. Now, of course, some authors create open source and actively solicit use by others. In that case, they do need to consider feedback from their users. But again, there's no divine right conferred on users that the author will address their every whim. Fork and fix should be the first option - with no expectation it'll be upstreamed.