Should FSFE provide some kind of platform for community to discuss and propose coding standards?
Rationale
The (F)LOSS ecosystem is currently mostly focusing on quantity over quality which results in bloat of software that is not reliable in a mission critical environment (and thus making it inferior to proprietary software) or software that requires “reinventing the wheel” because of authors bad decision (lack of abstracting → Malpractice).
This proposal is expected to contribute to the solution.
Practical Example
Example enforcing IEEE Std 1003.1-2017 to check if variable ‘number’ storing integer 5 is passing reqular expression [0-9] in shell vs bourne again shell.
Bad code:
#!/bin/bash
number=
"5"
if
[[
"
$number
"
=~ [0-9] ]];
then
whatever;
fi
- Works only on systems with dynamic linking - Bash is not part of standard portable OS → Not portable
Good code:
#!/bin/sh
# shellcheck shell=sh # Written to comply with IEEE Std 1003.1-2017 [http://get.posixcertified.ieee.org/](http://get.posixcertified.ieee.org/) number=
"5"
case
"
$number
"
in
[0-9]) whatever;
esac
---
Discussion at: https://community.fsfe.org/t/fsfe-defined-coding-standards/597
-- - Krey
Hi,
On Monday, 2021-02-08 10:56:43 +0000, Jacob Hrbek wrote:
Should FSFE provide some kind of platform for community to discuss and propose coding standards?
Before discussing coding standards we should rule out bad Mail User Agents that produce totally unusable text/plain from text/html in their multipart/alternative:
Bad code:
#!/bin/bash
number=
"5"
if
[[
"
$number
"
=~ [0-9] ]];
then
whatever;
fi
- Works only on systems with dynamic linking
- Bash is not part of standard portable OS → Not portable
Good code:
#!/bin/sh
# shellcheck shell=sh # Written to comply with IEEE Std 1003.1-2017 [http://get.posixcertified.ieee.org/](http://get.posixcertified.ieee.org/) number=
"5"
case
"
$number
"
in
[0-9]) whatever;
esac
As sent, both are bad code.
Eike
On Tue, 2021-02-09 at 22:40 +0100, Eike Rathke wrote:
Hi,
On Monday, 2021-02-08 10:56:43 +0000, Jacob Hrbek wrote:
Should FSFE provide some kind of platform for community to discuss and propose coding standards?
Before discussing coding standards we should rule out bad Mail User Agents that produce totally unusable text/plain from text/html in their multipart/alternative:
I don't consider those Mail User Agents as bad, producing text/plain from text/html is a security feature in some mail clients, for example in Evolution.
Bad code:
#!/bin/bash
number=
"5"
if
[[
"
$number
"
=~ [0-9] ]];
then
whatever;
fi
- Works only on systems with dynamic linking
- Bash is not part of standard portable OS → Not portable
Good code:
#!/bin/sh
# shellcheck shell=sh # Written to comply with IEEE Std 1003.1-2017 [< http://get.posixcertified.ieee.org/%3E%5D(http://get.posixcertified.ieee.org... ) number=
"5"
case
"
$number
"
in
[0-9]) whatever;
esac
As sent, both are bad code.
Eike
Discussion mailing list Discussion@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/discussion
This mailing list is covered by the FSFE's Code of Conduct. All participants are kindly asked to be excellent to each other: https://fsfe.org/about/codeofconduct
Hi Valerio,
On Wednesday, 2021-02-10 09:13:35 +0100, Valerio Bellizzomi wrote:
On Tue, 2021-02-09 at 22:40 +0100, Eike Rathke wrote:
Before discussing coding standards we should rule out bad Mail User Agents that produce totally unusable text/plain from text/html in their multipart/alternative:
I don't consider those Mail User Agents as bad, producing text/plain from text/html is a security feature in some mail clients, for example in Evolution.
You misunderstood. I didn't say that text/plain is a bad thing, but the text/plain that your MUA generated for the text/html is catastrophic, resulting in unlegible and even wrong "source code" for people who do not use HTML mailers.
Eike
On 2/9/21 10:40 PM, Eike Rathke wrote:
Hi,
On Monday, 2021-02-08 10:56:43 +0000, Jacob Hrbek wrote:
Should FSFE provide some kind of platform for community to discuss and propose coding standards?
Before discussing coding standards we should rule out bad Mail User Agents that produce totally unusable text/plain from text/html in their multipart/alternative:
Bad code:
#!/bin/bash
number=
"5"
if
[[
"
$number
"
=~ [0-9] ]];
then
whatever;
fi
- Works only on systems with dynamic linking
- Bash is not part of standard portable OS → Not portable
Good code:
#!/bin/sh
# shellcheck shell=sh # Written to comply with IEEE Std 1003.1-2017 [http://get.posixcertified.ieee.org/](http://get.posixcertified.ieee.org/) number=
"5"
case
"
$number
"
in
[0-9]) whatever;
esac
As sent, both are bad code.
Eike
-- OpenPGP/GnuPG encrypted mail preferred in all private communication. GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A Use LibreOffice! https://www.libreoffice.org/ _______________________________________________ Discussion mailing list Discussion@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/discussion
This mailing list is covered by the FSFE's Code of Conduct. All participants are kindly asked to be excellent to each other: https://fsfe.org/about/codeofconduct
Justify bad code and elaborate on bad mail user agents.
Hi kreyren,
On Wednesday, 2021-02-10 08:46:15 +0000, kreyren@rixotstudio.cz wrote:
Justify bad code and elaborate on bad mail user agents.
No. But if these produce text I can't read and cripple "source code" to be discussed there's no incentive to even follow a discussion.
Eike
Hello.
I don't think FSFE should provide coding standard: everybody is already doing that. Some coding standard make no sense, some are ugly, some are good; you only need to choose yours -- or be forced by your employer.
The problem your describe is that of bashisms. I agree we should use /bin/sh in published scripts (and ensure our own sh is not some featureful derivation).
This applies to all extensions: any extension is not portable by default, using it before it becomes ubiquitous is going to cause problems, sooner or later. But this position is not the most fashionable nowadays. You can fight this battle, and loose it.
Thanks for remininding about the issue, I recently had proplems with a mate's bashisms and small embedded systems.
/alessandro
Hi all,
Am 10.02.21 um 13:10 schrieb Alessandro Rubini:
The problem your describe is that of bashisms. I agree we should use /bin/sh in published scripts (and ensure our own sh is not some featureful derivation).
I think one should not publish any shell scripts any more except for the most trivial cases.
Shell code just is hard to read, not portable between systems at all, has very bad error handling, is hard to impossible to test, in short unmaintainable. This gets even worse if you use only POSIX features.
My 2 cents Michael
On 2/10/21 1:10 PM, Alessandro Rubini wrote:
everybody is already doing that
I don't believe that more standards are a bad thing.
Some coding standard make no sense, some are ugly, some are good; you
only need to choose yours -- or be forced by your employer.
Agree that some or even majority of them doesn't make any sense and are terrible in general thus this proposal to develop them as a set of multiple standards instead of one huge standard to allow developers to cherry-pick the one they want to follow and discuss them for their projects.
Hi,
Apart from the principal discussion whether FSFE is well-equipped to define "coding standards" without defining a scope for that discussion, I'd like to address the introductory paragraph that almost reads as FUD to me:
The (F)LOSS ecosystem is currently mostly focusing on quantity over quality
Do you have any evidence of this? Intuitively, I would rather assume the opposite: proprietary software has a higher incentive to focus on quantity over quality, while writing FLOSS software means that one's code is under public scrutiny and writing "bad" code can potentially harm your future job prospects.
Data from code analyser vendors seems to support this thesis: https://blog.semmle.com/open-source-vs-proprietary-software/ http://www.ciol.com/coverity-scan-report-source-software-quality-outpaces-pr...
If there is newer data or academic research that suggests otherwise, I'd like to hear about it.
which results in bloat of software that is not reliable in a mission critical environment (and thus making it inferior to proprietary software)
Is that the reason why all core internet protocols are dominated by FLOSS implementations?
or software that requires “reinventing the wheel” because of authors bad decision (lack of abstracting → Malpractice).
Yes, "reinventing the wheel" or "not invented here" (NIH) does also affect FLOSS communities. Yet proprietary software development practically depends on it.
This proposal is expected to contribute to the solution.
You should start with defining the problem, ideally in a quantifiable way. Here are questions that your problem description could potentially benefit from:
What is the problem domain? My guess it's not "the (F)LOSS ecosystem", but judging on your example it may be as narrow as "bourne shell scripting". The great thing about this is that providing coding standards or best practices for a narrow set of languages and use-cases is far easier (meaning "actually possible") than for each and every programming language in present- day use.
Is there prior art that is relevant? Best practices are highly valued in both FLOSS and proprietary environments. Hence there are already ample resources, albeit not necessarily evenly distributed among programming languages and domains. As an example, consider the C++ best guidelines:
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#main
Looking at academic literature may also yield good approaches for your problem description.
What makes the FSFE well-suited to contribute to the solution? I mean, yes, I support the FSFE and I think the world would be a worse place without it - not to mention the many great individuals that are part of FSFE and the FSFE community. I also don't want to discourage you from discussing topics like this on FSFE community channels. After all, we all care about creating high quality FLOSS software that empowers all users.
But going back to my C++ example: who could be better suited to providing best practices for a language than the language community itself?
Regards, Johannes
On 2/11/21 11:58 PM, Johannes Zarl-Zierl wrote:
Hi,
Apart from the principal discussion whether FSFE is well-equipped to define "coding standards" without defining a scope for that discussion, I'd like to address the introductory paragraph that almost reads as FUD to me:
The (F)LOSS ecosystem is currently mostly focusing on quantity over quality
Do you have any evidence of this? Intuitively, I would rather assume the opposite: proprietary software has a higher incentive to focus on quantity over quality, while writing FLOSS software means that one's code is under public scrutiny and writing "bad" code can potentially harm your future job prospects.
Data from code analyser vendors seems to support this thesis: https://blog.semmle.com/open-source-vs-proprietary-software/ http://www.ciol.com/coverity-scan-report-source-software-quality-outpaces-pr...
If there is newer data or academic research that suggests otherwise, I'd like to hear about it.
[...]
But going back to my C++ example: who could be better suited to providing best practices for a language than the language community itself?
As a software professsional who is reasonably OCD over coding standards I also think this is not the FSFE's task.
First, as Johannes say, various language communities do a good job of publishing suggested standards.
Second, the ultimate goal of an organization like the FSFE is that more software, ultimately *all* software, should be free. This replies regardless of its quality or coding standards. We would not reject Microsoft releasing Windows under the GPL if the code happened to be of bad quality.
Third, many free software communities have really excellent code. I often have the pleasure of debugging code in the Django framework, e.g., and it's normally a pleasure to read.
Best regards, Carsten
On 2/11/21 11:58 PM, Johannes Zarl-Zierl wrote:
Hi,
Apart from the principal discussion whether FSFE is well-equipped to define "coding standards" without defining a scope for that discussion, I'd like to address the introductory paragraph that almost reads as FUD to me:
The (F)LOSS ecosystem is currently mostly focusing on quantity over quality
Do you have any evidence of this? Intuitively, I would rather assume the opposite: proprietary software has a higher incentive to focus on quantity over quality, while writing FLOSS software means that one's code is under public scrutiny and writing "bad" code can potentially harm your future job prospects.
I would agree that keeping the software open-source in general helps it's integrity and robustness if the project is popular enough to attract an attention from parties that can actually do the required review, but I consider the lack of tests and CI implementation in relation to how the review process is self-evident.
For example projects such as cargo-make https://github.com/sagiegurari/cargo-make do a really good job at making sure that the software works (https://github.com/sagiegurari/cargo-make/pull/503), but majority of the (F)LOSS projects are not that way, because people don't see the value in caring about their own projects even though they are paid for it on LOSS model such as lutris (https://github.com/lutris/lutris) which based on my experience rarely works reliably and outside of arch linux which makes it into an inferior alternative to digital distribution software such as steam.
I would also argue that not everyone in (F)LOSS cares about their future job in Computer Science to have such a motivation to write a good software especially if their FLOSS software is their main source of income such as lutris example thus why we should as a community enforce the code quality otherwise there is really no motivation for these developers to care.
Data from code analyser vendors seems to support this thesis: https://blog.semmle.com/open-source-vs-proprietary-software/ http://www.ciol.com/coverity-scan-report-source-software-quality-outpaces-pr...
If there is newer data or academic research that suggests otherwise, I'd like to hear about it.
Your data is an old news article from 2014 without any legitimate source provided or peer-review that i can see and what looks to be a self-promotion by a non-indeptendent party (Semmle) to promote LGTM software without providing the raw data for peer-review in a scope that assumes only projects hosted on GitHub.
As said i consider this to be self-evident otherwise we would see FLOSS used in government (in relation to central europe) and on business level that is almost never the case unless the business is around higher end to understand the benefits of FLOSS and how to implement it in a sane way, but i am happy to discuss this further if you don't think it to be a valid argument.
which results in bloat of software that is not reliable in a mission critical environment (and thus making it inferior to proprietary software)
Is that the reason why all core internet protocols are dominated by FLOSS implementations?
Would agree that this doesn't apply to said internet protocols and majority of infrastracture-related software that people rely on and are mostly (F)(L)OSS for political reasons such as Bind9 (as far as i understood the reasoning).
or software that requires “reinventing the wheel” because of authors bad decision (lack of abstracting → Malpractice).
Yes, "reinventing the wheel" or "not invented here" (NIH) does also affect FLOSS communities. Yet proprietary software development practically depends on it.
That was rather meant on the development process itself to avoid major design failures such as GTK which generates movements such as https://stopthemingmy.app/ composed of "FLOSS developers" that are doing their best to restrict Freedom-0 and Freedom-3 on upstream level. - https://github.com/do-not-theme/do-not-theme.github.io/issues/17 - https://github.com/do-not-theme/do-not-theme.github.io/issues/3 - https://github.com/do-not-theme/do-not-theme.github.io/issues/16 - https://github.com/do-not-theme/do-not-theme.github.io/issues/15 - https://github.com/do-not-theme/do-not-theme.github.io/issues/7
We as a community should educate and enforce the four freedoms as these projects will only spread like cancer and should be labeled as FOSS (Free as in price and without Libre).
This proposal is expected to contribute to the solution.
You should start with defining the problem, ideally in a quantifiable way. Here are questions that your problem description could potentially benefit from:
What is the problem domain? My guess it's not "the (F)LOSS ecosystem", but judging on your example it may be as narrow as "bourne shell scripting".
To clarify i use shell scripting as an example as i assume that since it's the scripting language used in terminal that everyone will be able to understand what i am trying to express with it.
And to clarify on the problems in terms of the use of Free Software on example in Czechia which is my main interest as current coordinator for FSFE-Czechia (currently disputed by Max) representing the interest of interested parties this is about trust and robustness so that the software could be used for mission critical environment e.g. railroad management to avoid deadly accidents tracked at https://cs.wikipedia.org/wiki/Kategorie:%C5%BDelezni%C4%8Dn%C3%AD_nehody_v_%... most of which are caused by software malfunction.
There is no trust in Free Software to be used in this area as it doesn't come with warranty that could ensure confidence by offsetting the economical impact and it's widely seen as inferior alternative due to it's code quality according to my personal experience and research thus the code quality has to be a strong for us to make a strong argument for Free Software.
Thus I believe that developing such standard to reduce the amount of design failures and enforces best practices that i see as lacking.
The great thing about this is that providing coding standards or best practices for a narrow set of languages and use-cases is far easier (meaning "actually possible") than for each and every programming language in present- day use.
Is there prior art that is relevant? Best practices are highly valued in both FLOSS and proprietary environments. Hence there are already ample resources, albeit not necessarily evenly distributed among programming languages and domains. As an example, consider the C++ best guidelines:
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#main
Looking at academic literature may also yield good approaches for your problem description.
What makes the FSFE well-suited to contribute to the solution? I mean, yes, I support the FSFE and I think the world would be a worse place without it - not to mention the many great individuals that are part of FSFE and the FSFE community. I also don't want to discourage you from discussing topics like this on FSFE community channels. After all, we all care about creating high quality FLOSS software that empowers all users.
But going back to my C++ example: who could be better suited to providing best practices for a language than the language community itself?
I believe that FSF/FSFE/FSFLA/(FSF-australia) are the only credible authorities in FLOSS to enforce such best practices and standard as majority if not all developers that care about the liberty of their software are looking up to these foundations (me included!). These foundations simply by writting and publishing code are having a major influence on the whole Computer Science just from my experience people are studying the source code just to learn how to be a better developer.
So the foundation members already have the authority that they may not even know about so this is just to move it into a coordinated effort and utilize this authority in a controlled environment which is something that i would argue we desperately need to have a strong argument for Free Software over proprietary.
Would agree that some already present standards are usable such as the once used for common lisp, but then there are standards hidden behind a paywall with community maintained that are mostly insane such as C and it's open-standard that from my experience is just chaos of people arguing over one another without common goal.
Can't speak for C++ as i am not using it in regular bases (i prefer rustlang in the scope of work).
Just for the sake of completeness:
Am 13.02.21 um 05:11 schrieb Jacob Hrbek:
as current coordinator for FSFE-Czechia (currently disputed by Max)
AFAICT, the only person who claims that there is a group "FSFE-Czechia" and calling yourself the coordinator of that group is you. Please stop this. It doesn't help anything.
Thanks,
On 2/14/21 10:35 PM, Reinhard Müller wrote:
Just for the sake of completeness:
Am 13.02.21 um 05:11 schrieb Jacob Hrbek:
as current coordinator for FSFE-Czechia (currently disputed by Max)
AFAICT, the only person who claims that there is a group "FSFE-Czechia" and calling yourself the coordinator of that group is you. Please stop this. It doesn't help anything.
Thanks,
Reinhard Müller * Financial Team Free Software Foundation Europe
Discussion mailing list Discussion@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/discussion
This mailing list is covered by the FSFE's Code of Conduct. All participants are kindly asked to be excellent to each other: https://fsfe.org/about/codeofconduct
Group approved by eal to my knowledge where from my research he didn't inform the rest of the FSFE about the status of the group and is now not available at the moment thus for the time being i've removed affiliation with FSFE and halted the activity until the matter is resolved per your request and will be waiting for further instructions.
On 15.02.21 07:27, kreyren@rixotstudio.cz wrote:
On 2/14/21 10:35 PM, Reinhard Müller wrote:
Just for the sake of completeness:
Am 13.02.21 um 05:11 schrieb Jacob Hrbek:
as current coordinator for FSFE-Czechia (currently disputed by Max)
AFAICT, the only person who claims that there is a group "FSFE-Czechia" and calling yourself the coordinator of that group is you. Please stop this. It doesn't help anything.
Thanks,
Reinhard Müller * Financial Team Free Software Foundation Europe
Discussion mailing list Discussion@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/discussion
This mailing list is covered by the FSFE's Code of Conduct. All participants are kindly asked to be excellent to each other: https://fsfe.org/about/codeofconduct
Group approved by eal to my knowledge
absolutely disagree! I told you that in order to create a local group, you should start to publicly announce meetings on the fsfe infrastructure with the aim of creating a local group in Czechia and held these meetings in public. There you get to know other fsfe people, you find a transparent working mode and a project to work on and regularly invite new members on our infrastructure to join the group. And then, once you decided as a group _together_ to exist and to work further, to vote on a coordinator and a vice-coordinator together, then you can call it a new local group.
There is no way for you to go around our procedures and call yourself alone an offical FSFE Czechia. Please stop this.
Best, Erik
On 2/15/21 1:52 PM, Erik Albers wrote:
On 15.02.21 07:27, kreyren@rixotstudio.cz wrote:
On 2/14/21 10:35 PM, Reinhard Müller wrote:
Just for the sake of completeness:
Am 13.02.21 um 05:11 schrieb Jacob Hrbek:
as current coordinator for FSFE-Czechia (currently disputed by Max)
AFAICT, the only person who claims that there is a group "FSFE-Czechia" and calling yourself the coordinator of that group is you. Please stop this. It doesn't help anything.
Thanks,
Reinhard Müller * Financial Team Free Software Foundation Europe
Discussion mailing list Discussion@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/discussion
This mailing list is covered by the FSFE's Code of Conduct. All participants are kindly asked to be excellent to each other: https://fsfe.org/about/codeofconduct
Group approved by eal to my knowledge
absolutely disagree! I told you that in order to create a local group, you should start to publicly announce meetings on the fsfe infrastructure with the aim of creating a local group in Czechia and held these meetings in public. There you get to know other fsfe people, you find a transparent working mode and a project to work on and regularly invite new members on our infrastructure to join the group. And then, once you decided as a group _together_ to exist and to work further, to vote on a coordinator and a vice-coordinator together, then you can call it a new local group.
There is no way for you to go around our procedures and call yourself alone an offical FSFE Czechia. Please stop this.
Best, Erik
-- No one shall ever be forced to use non-free software Erik Albers | Programme Manager & Communication | FSFE OpenPGP Key-ID: 0x8639DC81 on keys.gnupg.net _______________________________________________ Discussion mailing list Discussion@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/discussion
This mailing list is covered by the FSFE's Code of Conduct. All participants are kindly asked to be excellent to each other: https://fsfe.org/about/codeofconduct
For the record i went through the process.
i've contacted FSFE about creating the local group and scheduled call with erik which took around an hour where he explicitly said that the group is approved on which i followed up with a plan.
On the call we were discussing that this exact scenario where FSFE disputes the group status can't happen, because it would mean that the group would lost it's members and the work that has been done on it would be wasted.
It happened anyway so he either didn't listen the whole time, didn't care or knew this would happen and did it intentionally.
Now i lost around 2 months of my life working on this (me and group members were working on this before the group was requested) and around 21 members while looking like an idiot to everyone wishing i never sent the request.
FWIW this is the most hostile working environments that i've been in 8 years. Everyone but floriansnow just seems to hate me the first day i've joined while not caring about me, czechia or anything i do.
I hope it will change one day and i will be looking forward to that day, but for now i no longer want to be affiliated with FSFE.
On 15 February 2021 19:38:56 UTC, kreyren@rixotstudio.cz wrote:
Now i lost around 2 months of my life working on this (me and group members were working on this before the group was requested) [...], but for now i no longer want to be affiliated with FSFE.
Please consider operating as a Free-Software-supporting association outside of FSFE, so the work and members are not all lost.
FSFE does good but is not the Messiah. The basic concept of a Foundation (special status for founders and founding procedures) is not in perfect harmony with free software IMO.
Regards,
Hi,
Am 16.02.21 um 12:42 schrieb MJ Ray:
Please consider operating as a Free-Software-supporting association outside of FSFE, so the work and members are not all lost.
FSFE does good but is not the Messiah. The basic concept of a Foundation (special status for founders and founding procedures) is not in perfect harmony with free software IMO.
To clarify: the legal status of FSFE is that of a registered association, not that of a foundation. There is no special status for founders.
Other than that, I agree with what you said: we are not the Messiah, and if you want to do things that are outside the scope of FSFE please don't let that stop you doing them anyway :-)
Thanks,
Trimming to get the context back...
On Saturday, 13 February 2021 05:11:23 CET Jacob Hrbek wrote:
The (F)LOSS ecosystem is currently mostly focusing on quantity over quality
[...]
I would also argue that not everyone in (F)LOSS cares about their future job in Computer Science to have such a motivation to write a good software especially if their FLOSS software is their main source of income such as lutris example thus why we should as a community enforce the code quality otherwise there is really no motivation for these developers to care.
In my experience, it is the broader discipline of software engineering that upholds the quality of software products, not computer science, at least when it comes to the delivery of that software to end users. To clarify, it is often not about the best algorithms or whatever people think of as computer science, but the tedious automation that needs to be done to make sure that mistakes have not been made in producing and delivering software systems.
I have worked in academia and in commerce and have found that people do indeed write software that achieves certain objectives, but the process around writing, documenting and maintaining the software involves engineering activities that are neglected. Software development, like many things, is in most cases a continuous, unceasing process; so is the pursuit of quality.
[...]
As said i consider this to be self-evident otherwise we would see FLOSS used in government (in relation to central europe) and on business level that is almost never the case unless the business is around higher end to understand the benefits of FLOSS and how to implement it in a sane way, but i am happy to discuss this further if you don't think it to be a valid argument.
I don't quite follow the argument here. Are you saying that a lack of quality in Free Software products causes government and business to choose proprietary solutions? And that this occurs because they would otherwise need to remedy the quality problems (documentation, deployment, and so on) in Free Software? And that the only way they would be motivated to do so is to understand the strategic case for Free Software?
I would broadly agree that the reason why Free Software sometimes does not get adopted can be due to a lack of immediate applicability. Indeed, I remember making the case that advocacy only goes so far because as soon as someone then turns round and asks for specific, usable Free Software solutions, there actually does need to be at least one usable solution in a given domain that doesn't involve excuses being made for why certain features are not there or not ready.
(There are, of course, other reasons for non-adoption of Free Software, like familiarity with existing products and processes, resistance to change, corruption, and so on.)
Thus, I ended up arguing for investment in Free Software development so that solutions exist that are ready for actual use. Sadly, there are still plenty of apologists for volunteer culture and the cost-cutting focus of certain factions of the "open source" movement.
And although some people are getting the message, it dismays me that instead of pursuing some kind of sustainable funding model, one sees the usual tendencies to go and ask for corporate or charitable grants, and it appals me that some of these grants could justifiably be regarded as a kind of philanthropic penance for how the money has been made (not naming any particular entity that I might be thinking of as I write this).
[...]
or software that requires “reinventing the wheel” because of authors bad decision (lack of abstracting → Malpractice).
Yes, "reinventing the wheel" or "not invented here" (NIH) does also affect FLOSS communities. Yet proprietary software development practically depends on it.
That was rather meant on the development process itself to avoid major design failures such as GTK which generates movements such as https://stopthemingmy.app/ composed of "FLOSS developers" that are doing their best to restrict Freedom-0 and Freedom-3 on upstream level.
- https://github.com/do-not-theme/do-not-theme.github.io/issues/17
- https://github.com/do-not-theme/do-not-theme.github.io/issues/3
- https://github.com/do-not-theme/do-not-theme.github.io/issues/16
- https://github.com/do-not-theme/do-not-theme.github.io/issues/15
- https://github.com/do-not-theme/do-not-theme.github.io/issues/7
We as a community should educate and enforce the four freedoms as these projects will only spread like cancer and should be labeled as FOSS (Free as in price and without Libre).
The phenomenon above is arguably less about philosophy and more about the practical issues around the design and evolution of a technology platform and the management and control issues that arise in the processes concerned. People asking that their "apps" not be themed are apparently annoyed at the technological churn and needless work created for them in the name of progress.
Their escape route might possibly be to fork the technologies on which their "apps" are based, but then they have to work against the entire ecosystem of upstream developers, distributions, and so on. The alternative is to lobby the upstream developers, some of whom work for rather large corporations (or are allied to those corporate interests) and ask for sympathy. I can tell you from personal experience that lobbying against needless change doesn't get much sympathy in this industry.
This actually leads to just one aspect of the sustainability problem our industry faces. Technological platforms that are ostensibly the product of lots of individuals turn out to be corporate endeavours after all, that their complexity escalates and can somehow still be supported by improving hardware technology, but where the experience of dealing with the technology and the burden of that technology itself threatens to impoverish and exclude entire groups of people from worthwhile progress in their own societies.
And, of course, there is the impact that escalated production and consumption of technology for no measurable resultant benefit has on our environment.
Paul