Sunday May 31st 2020 by SocraticDev
The labels FOSS and F/OSS ('Free and Open-Source Software' and 'Free / Libre and Open-Source Software') describe a development model for open source software. According to a flexible legal license, everyone is allowed to execute, study and redistribute the source code. As well as provide extra features in order to sell it as product or service. This type of software differs from proprietary software whose source code is protected, more difficult to modify and whose use is chargeable.
The operating systems Windows, MacOs and Unix are an example of proprietary software. While the GNU/Linux distributions remain FOSS. This case illustrates the free software ecosystem well because some distributions (operating systems) GNU/Linux intended for large organizations are accompanied by restrictive licenses and require significant annual fees.
benefits
The costs of developing and using free software are much lower than for proprietary software. You don't have to pay for licenses to use them, and most of the time collaborators develop on a voluntary basis. Some organizations may provide 'after-sales service' to users. This business model ensures the sustainability of the project while saving time and worry for end users who need specialized assistance.
The absence of a patent promotes technological innovation. Open-source licenses are simple and not restrictive. This has the effect of providing effective protection to community members while ensuring that they are not held back by legal considerations.
More eyes, more security - Red Hat, Open Source specialist
Free software is often safer than proprietary software. The source code is accessible to all: it is scrutinized by a multitude of experts and quickly corrected when necessary.
The source code being available to everyone: it becomes eternal. Free software has an almost infinite lifespan. Even if the community abandons a project, the source code will remain available for the use and improvement of the software.
some challenges
All the same, the development of free software has its challenges. Any organization wishing to turn to open source must assess the value it will recover from this effort. Making a project available in open-source is a lot of work: before, during and after. And there is the risk that our community of contributors abandons the project is always present ...
The organization must first determine how this effort will pay off. Then it must determine how her project will contribute to the community. To attract talented contributors, it is imperative that the project be profitable for them. No developer will work voluntarily on a project which is indifferent to them!
The culture of free software promotes respect, openness and transparency. All development work must be done in an open and public way. The community must be in constant communication. The project accepts contributions from any member of the community. Any input, be it code or additions to the roadmap, must be received and diligently reviewed by project administrators. Any feedback should be given promptly and publicly.
These requirements are necessary for the acquisition and maintenance of the bond of trust between the community and the project put forward by the organization. Any decision taken privately or unilaterally will erode this bond of trust. An alienated community will therefore have the right to leave the project with the code and continue development independently.
the unavoidable
The quality of the code is the first challenge of a free software project. Any self-respecting project imposes non-negotiable standards regarding code quality. Any code that does not meet the requirements will be refused by the main contributors. We talk as much about naming variables and functions as about using spaces instead of a tab. Good projects, like Apache and Google, provide extensive documentation of its standards with explanations justifying their adoption. The best projects require a substantial coverage of the source code by automated unit tests in order to avoid regressions.
Four text files (
.md) placed at the root of an open-source project are omnipresent in any free software project.
The LICENSE file contains the legal text setting out the rights and constraints of users of the source code. Most often, we will make a copy/paste of the text of the licenses commonly used like MIT or GNU.
The file named README.md explains the nature of the project. There is a description of the project. It explains how the project is useful to the community. And we inform employees of the resources available to answer their questions. The code repository website GitHub and GitLab even reads the MarkDown (.md) file and styles it to be displayed on the project's main page.
The file named CONTRIBUTING.md explains how to contribute to the project. It contains essential informations to frame the collaboration process. It explains the process to follow to create a new correction request. We suggest some features to implement in the short term. The product roadmap is listed there as well as the preferred (or prohibited) ways to communicate with the project managers.
For developers, we explain how to configure their development environment. We will even suggest an electronic template to use to submit a new feature or a fix via a pull request (or merge request in the GitLab ecosystem).
More and more projects contain a file CODE_OF_CONDUCT.md used to establish the social and ethical standards governing collaboration. It describes how we want participants to behave. We stress the importance of being warm and empathetic. In other words, treating others as we would like to be. Emphasis is placed on respecting the opinions, culture and life experiences of each. Recognizing that we are all fallible, we recommend taking the initiative to apologize when appropriate and, most importantly, to learn from these unpleasant experiences. Finally, we recommend prioritizing the good of the project and the community versus our personal ambitions and preferences.
As with legal license files, there is a 'Code of Conduct' document accepted by hundreds of projects that can be 'copy and paste' to the root of your project directory: Contributor Covenant: A Code of Conduct for Open Source Projects.
Translated from french by Google Translate
sources
https://redhatofficial.github.io/#!/main
https://opensource.com/article/17/6/what-know-you-open-source-your-project
