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-proprietary-code/ > > 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_%C4%8Cesku 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). -- - Krey
OpenPGP_0x31AE4020956E0A9A.asc
Description: application/pgp-keys
OpenPGP_signature
Description: PGP signature
_______________________________________________ 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
