This book is about being open source code. Not about software development. This book isn’t going to teach you how to make an application or website, a mobile app, or anything like that. Instead, this book will teach you how to be a good open source citizen; how to be a collaborator and community member; how to give back through code and documentation.
Open source is an American English term used to refer to a computerized component, often software (but hardware as well), whose original source code is made available and licensed in such a way that users are typically allowed to modify and redistribute unless the license’s authors specify otherwise. Open source projects include most of the flavors of UNIX, PostgreSQL, MySQL, Sendmail, and Mozilla Firefox.
Get to know GitHub
GitHub is the most popular platform for open source collaboration, so you’ll probably use it when exploring the world of OSS. First, you need to create a GitHub account and read the guide that helps you get started. On GitHub, you can contribute to projects by submitting issues and contributing code. Submitting issues means sending messages about errors in applications and suggesting ways to fix them. Contributing code involves sending pull requests with your corrections and improvements.
Step by Step Guide on How to Contribute to Open Source
When we say contributing to open-source, it does not necesarilly mean that you need to know how to code. There are different ways in which you can contribute even if you are a non-coder – but having some coding skills will help you (and the projects) out a lot.
Some common contributions can be through:
- Adding a description to a project’s documentation to elaborate on a certain point, mostly referred to as a README file (check this guide on how to write a Good README file).
- Giving guidance on a specific project and how to use it.
- Adding sample output to show how the code works.
- Writing in-depth tutorials for the project.
- Adding translation for a project – A good place to start with this might be with the freeCodeCamp’s translation program.
- Answering questions about a project (like on Stack Overflow or Reddit)
- You can offer to mentor another contributor.
- You can fix typos and arrange the project’s work folder correctly.
All these ways, and many more, count towards contributions. Now what exactly should you know before you start contributing to an OS project?
Offering paid support is one of the most straightforward revenue streams for all kinds of open source projects. As a project maintainer, you have a lot of knowledge about the codebase. This puts you in the position to offer consultancy or support services to companies that want to use your code.
On the other hand, offering paid support doesn’t provide a scalable business model for open source projects. Because most projects are maintained by a few developers, there’s limited time for them to offer support to companies. Bear in mind the time required to improve the functionality and maintain the codebase.
In conclusion, it’s an effective way to earn some money as an open source maintainer and keep the project going.
A simple policy for using open source code
The usage policy is an essential component of any compliance program. This set of rules is included in your open source strategy document (you have one, right?) and made available to everyone for easy reference.
The usage policy ensures that any software (proprietary, third-party, or open source) that makes its way into the product base has been audited, reviewed, and approved. It also ensures that your company has a plan to fulfill the license obligations resulting from using the various software components, before your products make it to customers.
There is no need to make a lengthy or complicated document. A good open source usage policy includes six simple rules:
- Engineers must receive approval from the OSRB before integrating any open source code in a product.
- Software received from third parties must be audited to identify any open source code included, which ensures license obligations can be fulfilled before a product ships.
- All software must be audited and reviewed, including all proprietary software components.
- Products must fulfill open source licensing obligations prior to customer receipt.
- Approval for using a given open source component in one product is not approval for another deployment, even if the open source component is the same.
- All changed components must go through the approval process.
Learn the basics
When working with GitHub, you should know how to use Git – one of the most popular version control tools (also known as revision control tools). Because developers constantly make changes to their code, they need a system that can manage those changes in a central repository. In this way, everyone involved in the development process can download a given piece of software, make changes, and submit updates.
Software as a Service
An open source project that has generated plenty of demand can choose to offer a Software as a Service (SaaS) business model. This model is most viable for projects that offer a complete application, such as a publishing platform, monitoring tool, or marketing automation tool.
Developers can choose to host the software themselves. However, this means that they have to take care of security, security, and maintenance.
It’s often much easier and cheaper to pay for a managed offering under a SaaS model. Developers pay a monthly fee to use the hosted solution. Therefore, they can focus on the tool itself instead of all maintenance-related tasks. Moreover, a marketing or content team often doesn’t have the required technical knowledge to host a solution themselves. For that reason, a SaaS solution is a great alternative to make money from open source software.
5-stage code review process
Once you have a policy in place, you must plan and create a process that makes it easy to apply the policy. Your job is to grease the wheels for developer use of open source and contribution to open source projects.
“If your code review process is overly burdensome, you’ll slow innovation or provide a good excuse for developers to circumvent the process completely.”
Ibrahim Haddad – Vice President of R&D and Head of the Open Source Group at Samsung Research America
The process begins by scanning the source code of the software package in question, then moves on to identifying and resolving any discovered issues, performing legal and architectural reviews, and making a decision regarding the usage approval.
The diagram, below, illustrates a simplistic view of a compliance usage process. In reality, the process is much more iterative in nature. Keep in mind that these phases are for illustration purposes and may need to be modified depending on your company’s own needs and open source program configuration.
Let’s walk through each stage in the process.
Source Code Scan
In the source code scanning phase, all the source code is scanned using a specialized software tools (there are many commercial vendors that offer such tools in addition to a couple open source alternatives).
This phase typically kicks off when an engineer submits an online usage form. (See the sample usage form and rules for using it, below.) The form includes all the information about the open source component in question, and specifies the location of the source code in the source code repository system.
The form submission automatically creates a compliance ticket in a system such as JIRA or Bugzilla and a source code scanning request will be sent to the designated auditing staff.
Periodic full platform scans should also take place every few weeks to ensure that no open source software component has been integrated into the platform without a corresponding form. If any was found, then a JIRA ticket is automatically issued and assigned to the auditing staff.
Some of the factors that can trigger a source code scan include:
- An incoming usage form, usually filled out by engineering staff.
- A periodically scheduled full platform scan. Such scans are very useful for uncovering open source code that snuck into your software platform without a usage form.
- Changes in a previously approved software component. In many cases, engineers start evaluating and testing with a certain version of an OSS component, and later adopt that component when a new version is available.
- Source code is received from a third-party software provider who may or may not have disclosed open source.
- Source code is downloaded from the web with an unknown author and/or license, which may or may not have incorporated open source code.
- A new proprietary software component enters the build system where engineering may or may not have borrowed open source code and used it in a proprietary software component.
After the code is scanned, the scanning tool produces a report that provides information on:
- Known software components in use, also known as the software Bill of Materials (BoM)
- Licenses in effect, license texts, and summary of obligations
- License conflicts to be verified by legal
- File inventory
- Identified files
- Code matches
- Files pending identification
- Source code matches pending identification
This handbook provides an introduction to the Open Source world from a programmer’s point of view. It’s a collaborative work, providing insight from teachers, hackers and distributed peer reviewers.