This post provides an overviews on free and open-source software (FOSS) projects.
Assessing whether a Software Project should be FOSS
The answer to whether a software project should be FOSS or not depends on cultural beliefs, interests, needs and environment.
Some individuals and organization, like the Free Software Foundation (FSF), think that all software should be FOSS whatever the situation. If you are of that opinion, then it is coherent that you endeavor a FOSS project.
Eric S. Raymond states in his essay “The magic cauldron”, section “Knowing when to let go”, that “a project must be FOSS when the benefits of being opened exceeds the benefit of being closed“. These benefits do not have to be necessarily economical.
He also points that it must be assessed whether the value of the program is in its sales value or use value.
- Sales value is the monetary worth or revenue generated from the sale of the software product.
- Use value is the utility and functionality that the software provides to its users.
If the value of the product is mostly in its use, it is more probable that the project should be opened.
The sales value would be important in case that the organization or individual operations are based on selling the software project as a product. The sales value would be nonexistent and the use value important in case it is an internal tool whose use benefits the organization or individual.
It is also important to ask yourself if the value of your project is within the code itself (e.g., a disruptive and exclusive algorithm) or the team and service offer that are behind.
Another question is if you mind others using the software for free or including it in their own projects (even the commercial ones).
These criteria is just to decide whether the project should be FOSS or not. Once you decide it is FOSS, you must take into account additional questions to choose the proper FOSS license.
Ensuring Resources on a FOSS Project
You can read a summary about how to get incomes from FOSS projects on this post.
Building FOSS Projects
You can read about the technical aspects about how to build a FOSS project on this post.
Legal Aspects of FOSS Projects
Some legal aspects to be taken into account when managing FOSS projects:
- Use of Open Licenses
- Contributor License Agreements (CLAs)
Use of Open Licenses
There are different types of software licenses available to choose, divided into the main categories FOSS and proprietary. You can review them on this post.
If you are making a FOSS project, it means you are using free and open source software licenses. Some of the most popular FOSS licenses are MIT, Apache 2.0 and GPL 2.0/3.0. You can find more details about FOSS licenses on this post.
It is coherent that you also use open licenses for the project components different to the source code, like documentation, images or sounds. You can find a list of open licenses for different types of content on this post.
Contributor License Agreements (CLA)
A Contributor License Agreement (CLA) is a document that defines the terms under which intellectual property has been contributed to a project or organization.
You may consider that all contributors of your project signs a CLA, though it is not mandatory.
You can read more about CLA on this post.
Assessing IT Security of FOSS Projects
To assess whether your FOSS project is secure, you can use the FOSS tool Scorecard, developed within OpenSSF. You can find the code repository on this external link.
You can check the level of security based on Scorecard of a GitHub project using the web tool on this external link.
You can find an introduction to Open Source Security Foundation (OpenSSF) on this external link.
Ubuntu information about vulnerability management on open source on this external link.
Building a Community around a FOSS Product
You can read this post about how to create a FOSS community.
You might also be interested in…
External Links
- Karl Fogel; “Producing Open Source Software: How to Run a Successful Free Software Project”, 2005