3 ms·

The way FOSS works engraves feature abundance - every contributor has some feature wish that they will add - most of them jumps on the project for that very fea

The way FOSS works engraves feature abundance - every contributor has some feature wish that they will add - most of them jumps on the project for that very feature. Both contributors and target audience values features and configurability, and "unpolished" parts (mostly meaning you need to click 2 submenus more, you need some config to be set or script it yourself) are not a problem. This is the very antithesis of a for-profit company being laser focused on some customer group and wanting to be cost efficient with resources.

jwells89 3y ago
Lack of polish also extends to some of the things like the TFA mentions, like incomplete SVG export functionality. Either way, I don't believe that polish and FOSS feature abundance necessarily have to be at odds; it just means that the project in question needs to have a process for developing new features to production-readiness. This can take form in any number of ways, for example using feature flags to keep things that aren't yet fully baked enabled only in beta/alpha builds — people happy with a less polished experience can use betas until the feature they need is ready for primetime while the greater userbase gets a better user experience.
opportune 3y ago
Kind of agree, kind of don’t. A lot of companies also bolt on as many features and integrations to their products as they need, to close sales or just because they think it will help expand their potential customer base. A lot of FOSS is maintained by people who don’t want to spend their free time shepherding some code they wrote turning into everything-software either. There is a particular failure mode in FOSS though - normally in businesses, prioritizing new features is done on the basis of how it will ultimately affect revenue (or reduce costs, simplify things, reduce maintenance burden - still money at the end of the day). For those FOSS projects that are open to new features from randoms, those individuals are mostly adding features they individually want, and the amount of investment in those features is limited mostly by their level of personal interest. So you end up with a set of features that is more stochastically chosen, and some unimportant or minor features may have a huge amount of complexity/configurability/feature-specific code because one person needed it.

jwells89 3y ago

Lack of polish also extends to some of the things like the TFA mentions, like incomplete SVG export functionality. Either way, I don't believe that polish and FOSS feature abundance necessarily have to be at odds; it just means that the project in question needs to have a process for developing new features to production-readiness. This can take form in any number of ways, for example using feature flags to keep things that aren't yet fully baked enabled only in beta/alpha builds — people happy with a less polished experience can use betas until the feature they need is ready for primetime while the greater userbase gets a better user experience.

opportune 3y ago

Kind of agree, kind of don’t. A lot of companies also bolt on as many features and integrations to their products as they need, to close sales or just because they think it will help expand their potential customer base. A lot of FOSS is maintained by people who don’t want to spend their free time shepherding some code they wrote turning into everything-software either. There is a particular failure mode in FOSS though - normally in businesses, prioritizing new features is done on the basis of how it will ultimately affect revenue (or reduce costs, simplify things, reduce maintenance burden - still money at the end of the day). For those FOSS projects that are open to new features from randoms, those individuals are mostly adding features they individually want, and the amount of investment in those features is limited mostly by their level of personal interest. So you end up with a set of features that is more stochastically chosen, and some unimportant or minor features may have a huge amount of complexity/configurability/feature-specific code because one person needed it.