In this article, I'll give a high-level explanation of what open source software (OSS) really is, its advantages in the modern technological world, how to use it, and some best practices to follow when using or contributing to an OSS project.

You will learn about widely used tools and techniques like GitHub and continuous integration, as well as what license to choose and how to promote diversity in open source projects.

You will also get to make your first open source contributions if you haven't done so already.

Both maintainers and contributors to open source projects should read this article.

Table of Contents

• What is OSS?
• What is Proprietary Software?
• Open Source Governance Models
• Why Use Open Source Projects (Advantages)?
• How to Work on an OSS Project
• How to Contribute to Open Source Projects
• Helpful Contribution Tips
• Continuous Integration and Delivery
• OSS Licenses and Legal Issues
• How to Choose a License for Your OSS Project
• How to Build Better Open Source Software Projects
• Understand that Leadership is Not Control
• Why Many OSS Projects Fail
• Diversity in OSS
• How to Use GitHub for Hosting OSS Projects

What is OSS?

OSS stands for Open Source Software. This type of software has freely accessible source code under a license that lets you examine, modify, and use that code without restriction.

What is Proprietary Software?

As opposed to OSS, many companies use proprietary software instead. Only the owners of proprietary software have complete access to the source code. Trusted partners can inspect the code once they've signed a non-disclosure agreement.

When using proprietary software, you must agree to a license that limits your ability to share the product.

Open Source Governance Models

Any organization that wants to succeed needs to be organized. It's important to carefully consider how the organization make decisions and who makes them.

Establishing a Governance Model helps determine how you can accomplish this. Let's talk about some of these models now.

Company-led Governance Model

In this model, software development and release management is handled by a single entity.

• External contributions may or may not be requested.
• Plans and release dates may not be publicly disclosed, and unofficial conversations may not be made public.
• Software is in the open (that is, it's public) when it is released.
• An example of this model is Android by Google.

Benevolent Dictatorship Governance Model

In this model, one individual has a dominant influence over the software – hence the term "dictator" (but in a much more positive sense here).

• The quality and effectiveness of the project are greatly influenced by the dictator's intelligence and managerial ability
• As a project matures, the maintainer writes less code, which can cut down on discussions and speed up progress.
• An example of this type of governance is Wikipedia

Board of Governors Governance Model (Tighter Regulation)

• All discussions are public via mailing lists, and collective choices are taken.
• The governing board decides who may contribute and whether new software is accepted.
• Releases are sometimes made less frequently, but they are carefully debugged.
• Examples are Debian and FreeBSD

Why Use Open Source Projects (Advantages)

There are quite a few advantages of going into open source development. Here are some of them:

• You collaborate with other contributors and often get better results
• The source code is often more secure and higher quality
• Using OSS best practices helps developers become better
• It reduces the development cost
• It decreases the time to market
• Customers can trust the quality because there are no secrets and they know what they are getting
• You'll have access to a vast array of inexpensive or free instructional aids for education and learning
• It's a good way to introduce beginners to the workplace

How to Work on an OSS Project

How to Contribute to Open Source Projects

Before contributing to open source projects, you should do some research around the project. Here are some ways to prepare:

Investigate the project

Before you start working on a project, you'll want to learn more about it. First, you should identify and understand the project workflow and styles it uses. Second, you should figure out the scope and nature of the work that needs doing.

Learn About its Communication Methods

Identify how the project maintainers communicate, either through study archives, a mailing list, or some online groups or chat platform.

Figure Out How Contributions Are Submitted

Contributions to the OSS project can be in the form of a mailing list, email, or – perhaps most commonly – through the Git version control system.

Study the Project's Previous History

Studying the history of the project is always a great idea so you know how it started and how it's been developed. Check if the project offers veteran contributors as mentors.

Be the Janitor at First

Offer your services for testing, finding bugs, and so on before you begin to submit code. This is healthy for beginners and people new to the OSS lifestyle. It's meant to be a temporary stage.

Understand the Project's Language

People frequently get interested in learning new programming languages by participating in open source projects that use those languages. But don't use the project as a way to learn the language.

Before thinking about making a software contribution, you should have some familiarity with the language. Most maintainers want qualified contributions only – they likely don't have time to teach you Python or JavaScript, for example.

So make sure you are proficient in the programming language(s) the project uses before contributing. Don't begin learning with a project.

Be Respectful

Being polite and respectful is an integral part in the OSS community as it involves diverse people. Always avoid flaming and trolling, as they have no place in the open source community.

Find a Balance

Try to achieve a balance between asking for feedback and suggestions early in the process and delaying your requests too long and overloading maintainers with a bunch of work at once.

Study and Understand the Project's Structure (DNA)

Most likely, the project already has a formal or informal leadership structure and a community-established culture.

Look into the project's purpose and the impetus behind it. Learn about how big or small the contributions typically are, how vibrant the community is, and what kind of license is being used.

Helpful Contribution Tips

To successfully make contributions to open source projects, there are some best practices you can follow.

First, you'll want to identify the maintainers, their work, and their techniques‌‌. There are projects with a single maintainer or many maintainers for individual subsystems.‌‌

Maintainers have various responsibilities as well. They need to be able to understand and review all submissions and verify that they do not add unnecessary complexity or defects. They should also make sure that these changes don't conflict with existing code.

You can develop a rapport with project maintainers and help them with debugging, reviewing, and other tasks as needed.

It's also important when you're working on a project to get input early and work in the open.

Here are some other quick tips to keep in mind:

1. The project probably has a lot of history, so check to make sure your issue hasn't already been resolved or someone else hasn't submitted a pull request to fix it. Your proposal might be a dated one.
2. Don't propose a fresh idea and have someone else carry it out. This shows that you're not committed to contributing.
3. If you are uncomfortable having other people look at your work often, OSS might not be the best fit for you. However, it could be an opportunity to learn how to take feedback and constructive criticism.
4. Contribute a little bit at a time – don't make a large code dump all at once.
5. Leave your ego at the door. You will sometimes get hash reviews and you need to be able to calmly internalize the feedback.
6. Do not discriminate against others.
7. Be patient and work to develop long-term professional relationships with others in the OSS community.

Continuous Integration and Delivery

When you're working on an OSS project, there will probably be established guidelines for the codebase to prevent conflicts, since many contributors will be working together on it. Testing can also help make sure the code works as it should.

What is Continuous integration?

Continuous integration techniques help ensure that testing is done often and that any issues won't go undiscovered for long. CI also helps make sure that scattered developers remain in sync, even if they're collaborating remotely all over the world.

The different stages of continuous integration are Integration, Delivery, and Deployment.

• Continuous Delivery: Translates to the practice of having a speedy and automatic delivery or release process once charges have been merged, and it is released to build clients.
• Continuous Deployment: When the product is actually released to clients

Examples of some continuous integration tools are:

• Jenkins
• CircleCI
• GitLab
• Travis

Continuous integration and delivery process. credits: Ronak Kumar Samantray

What Benefits Do CI/CD Have for OSS?

When a bunch of contributors are working on various aspects of a project from various perspectives and places, it must come together and not be in conflict. Additionally, fixing one issue shouldn't lead to the emergence of new issues elsewhere.

To accomplish all this, you must use some automated testing. So when testing, you should take into account many factors, such as:

• Whether you may implement modifications that overlap at the same time.
• Whether there are any conflicts.
• If the project is still able to compile after the changes are applied.
• If you make all the necessary changes, can you ship it?
• Does it work on all possible targets?

By ensuring that testing is constant, automated, and performed regularly, any problems that arise are swiftly fixed, and developers and users remain on the same page. And Continuous integration makes sure that any of these issues are minimized.

OSS Licenses an Legal issues

What is an Open Source License?

An open-source license is a sort of license for software that permits the use, modification, and/or sharing of the source code, blueprint, or design under specific terms and conditions.

Then end users or developers can review and modify the source code, blueprint, or design for their own use cases, curiosity, or troubleshooting requirements. Although it is not always the case, open-source licensed software is typically offered free of charge.

There are two types of software licenses that OSS projects generally use:

• Restrictive – the software remains open, but it has strict restrictions on any attempts to create proprietary closed goods. Changes to the code are also made available to future recipients, such as the GPL License.
• Permissive – these licenses don't demand updates and alterations to be publicly accessible, such as BSD and Apache fences.

Companies should consult with lawyers, either internal or external, to ensure that they do not violate copyrights and licenses when using code from open source projects.

There are many different licenses, so be careful. But once an organization establishes proper standard operating procedures, they must follow them for every project.

OSS Licenses help gives contributors a better idea about how to use and contribute to the source code.

Most Common Licenses

• GNU General Public License (GPL)
• MIT license
• Apache License 2.0
• BSD 3-Clause "New" or "Revised" license
• BSD 2-Clause "Simplified" or "FreeBSD" license
• GNU Library or "Lesser" General Public License (LGPL)
• Mozilla Public License 2.0
• Common Development and Distribution License

How to Choose a License for Your OSS Project

This is a crucial choice that has to be carefully considered because it may be difficult or even impossible to switch to a different license later in the project's existence.

Here are some things to consider when choosing one for your project:

• If you need a simple and permissive license, the MIT License is succinct and direct. It gives users practically unlimited access to your project. Examples of projects that use the MIT License include .NET and Rails.
• If you are more concerned about sharing improvements, almost everything can be done with your project under the GNU GPLv3, with the exception of disseminating closed source versions. Examples of projects employing this license include Ansible and Bash.

Read more about choosing the best license for your project suit here and here.

How to Build Better Open Source Software Projects

Understand that Leadership is not Control

An effective leader allows and encourages all participants to speak up and share their ideals while contributing. This often leads to more creative, high-quality work. So remember: loosen the reins when you can.

According to the well-known leadership paradigm known as the "Benevolent Dictator for Life" (BDFL), a project's controllers can only do so much if they take without giving back via teaching and moderating.

Also, if you're a maintainer, make sure you go through some training to learn how to be a good leader. Having a good mentor, for example, is vital in helping you acquire the information and skills required to become a good maintainer.

If the maintainer isn't helpful or supportive, new project participants will often move on to another project if they can't connect with an experienced contributor.

And finally, remember that an open-source project cannot succeed without trust. Reputations are built up over time, and new members should be cognizant of the past.

Why Many OSS Projects Fail

Most successful open source projects started off small and grew slowly. It's often hard to predict which projects will be successful and which won't.

Some of the reasons OSS project fail are:

1. They try to do the same thing as more mature programs.
2. They don't have good leadership.
3. There's a general lack of interest in their product/service.
4. They don't have enough developers
5. They don't have the correct license.

To combat these issues, here are some things to keep in mind:

• Make sure you have good and effective leadership, because this leads to more creative, high-quality work.
• Make sure your project has a well-defined governance structure and license.
• Encourage developers working on your project by providing resources and information to help them start contributing.

Diversity in OSS

The word "Open" in open source software (OSS) may be taken to mean a welcome, friendly environment. But this may only be a false promise if the project doesn't cultivate a welcoming atmosphere.

There are various forms of diversity, such as nationality and race, sex and gender identity, regional or geographic location, politics and belief systems, and so on.

It's important to respect and foster diversity in whatever ways you're able to do so. Some ways to foster diversity in the OSS space include:

• Respecting peoples beliefs and religions
• Not being biased against contributors for any reasons relating to race, sex, gender identity, location, beliefs, and so on.
• Valuing the contributors of all your contributors and engaging with them whenever possible.

How to Use GitHub for Hosting OSS Projects

Before GitHub, projects needed their own servers to host repositories. They also needed developers with extensive technical skills to set up, manage, and protect the repositories' integrity.

Developers can now primarily concentrate on the code by using GitHub or other Git hosting services like GitLab or Bitbucket.

Types of Repositories

There are two types of repositories on Git:

• Public Repositories that are accessible to everyone on the internet.
• Private Repositories, which are only accessible to you, people you explicitly share access with, and, for organization repositories, certain organization members.

Hands-on practice using GitHub for collaboration

Now we'll go through some basic steps, which, when you get them down, will provide you with the ultimate superpower in effective collaboration.

We will understand more fully by building a name biography website. So let's dive in:

Here's the Project Repo so you can follow along.

Step 1 – Fork the repository

This is to create a copy of the repository of the project in your gitHub account for more accessibility.

Then, click on the project link above and then fork the repository. To fork a repository, click the fork button at the top right corner of the GitHub website of the repo.

fork repository

Step 2 – Clone the repository

Cloning is creating a copy of the code online (your repository) on your local computer so you can work on it from there.

Cloning the repository on your computer is sometimes referred to as using a "local repository".

Click the code tab on the forked project on your GitHub and then click the copy code icon as show below:

clone repository

Now let’s go to your local computer. Open your favorite code editor (mine is VSCode) and open the inbuilt terminal. Then paste the code you copied after a 'git clone' command to clone this project repository to your local computer as shown below:

git clone <your-copy-code>

Now in your terminal, move to the generated project folder with the code below:

cd OSS-Contribution-Beginer

Step 3 – Create a branch from your local repository

Branches allow you to make changes without affecting other contributors' code and the main branch. it is always good to create your own branch when contributing to projects.

To do this is simple – just write the following code:

git branch ‘name-of-the-branch-you-want

e.g git branch caesar-name

Then you can switch to the branch you just created:

git checkout caesar-name

Step 4 – Make changes to the repository

In this scenario, our problem is to change the README.md to include your name, social media handle, and preferred emoji (you can browse how to get markdown emoji).

Scroll to the bottom of the README.md file. Add your name, social handles, and emoji to the list. Then save the changes.

Step 5 – ADD and COMMIT your changes

Adding and committing your changes is a way to save the changes you made into your local Git repository.

To achieve this, in your terminal run the following commands:

git add .

Then commit the code:

git commit –m “added my name bio”

Step 6 – Push it online

All we did in step five has been on your local computer or repository. Now it's time to push it to the original online repository on GitHub.

You can do this with the few lines of code below:

git push origin –u ‘your branch name’
i.e
git push origin –u caesar-name

Step 7 – Make a pull request (PR)

You can let people know about changes you've pushed to a branch in a GitHub repository by making a pull request.

Before your modifications are merged into the main branch, you can examine and validate the prospective changes with collaborators and the maintainer after you submit a pull request. You can even add follow-up contributions.

Go to your forked repository in GitHub online, see your resent changes that you just pushed, and click on compare and pull. Then click the create pull request button.

Pull request

pull request

Hurray! Congratulations. 🔥💡 You've successfully made your first open source contribution.

Summary

The open source ecosystem is a wide and interesting one, and you can benefit a lot from collaborating with others and making contributions.

In this article, you learned how open source projects work, what to consider when getting started, how to contribute, and how the different licenses work.

As always, I hope you enjoyed the article and learned something new. If you want, you can also follow me on LinkedIn or Twitter.

Cheers and see you in the next one! ✌️

• Taking a free or paid online programming course

• Reading a programming book

• Picking a personal project and hacking away to learn as you code

• Following along with an online tutorial project

• Keeping up to date with relevant programming blogs

Each of these methods will appeal to different people, and each one has elements that will definitely make you a better programmer. If you are an intermediate or advanced coder, it is almost certain that you've tried each of these methods at least once.

However, there is another method that the vast majority of developers overlook, which is a shame in my opinion because it has so much to offer. This method is to learn by reading, analyzing, and understanding existing, high-quality codebases!

We are lucky to live in a time where good code is often accessible for free via high-quality, free-and-open-source (FOSS) projects. And it takes less than a minute to clone down copies of these codebases to our local machines from sites like GitHub or BitBucket.

Furthermore, modern version control systems like Git allow us to view the code at any point in its development history. Clearly there is a wealth of information right in front of our noses!

In this article, we will discuss the original version of Git's code in order to highlight how reading existing code can help boost your coding skills.

We will cover why it's worth learning about Git's code, how to access Git's code, and review some related C programming concepts.

We will provide an overview of Git's original codebase structure and learn how Git's core functionalities are implemented in code.

Finally, we will recommend some next steps for curious developers to continue learning from Git's code and other projects.

Why Learn About Git's Code?

Git's codebase is an incredible resource for intermediate developers to further their programming knowledge and skills. Here are 7 reasons why it's worth digging into Git's code:

1. Git is probably the most popular software dev tool in use today. In short, if you're a developer, you probably use Git. Learning how Git's code works will give you a deeper understanding of an essential tool you work with every day.

2. Git is interesting! Git is a versatile tool that solves many interesting problems to allow developers to collaborate on code. As a curious human, I thoroughly enjoyed learning more about it.

3. Git's code is written in the C programming language, which offers a great opportunity for developers to branch out into an important language they may not have used much before.

4. Git makes use of many important programming concepts, including content-addressable databases, file compression/inflation, hash functions, caching, and a simple data model. Git's code illustrates how these concepts can be implemented in a real project.

5. Git's code and design are elegant. It is a great example of a functional, minimalist codebase that accomplishes its goal in a clear, effective way.

6. Git's initial commit is small in size – it is made up of only 10 files, containing less than 1,000 total lines of code. This is very small compared to most other projects and is very manageable to understand in a reasonable amount of time.

7. The code in Git's initial commit can be compiled and executed successfully. This means you can play with and test the original version of Git's code to see how it works.

Now, let's take a look at how to access the original version of Git's code.

How to check out Git's initial commit?

The official copy of Git's codebase is hosted in this public GitHub repository. However, I created a fork of Git's codebase and added extensive inline comments to the source code, to help developers easily read through it line by line.

Since I worked off of the very first commit in Git's history, I named this project Baby Git. The Baby Git codebase is located in this public BitBucket repository.

I recommend cloning the Baby Git codebase to your local machine by running the following command in your terminal:

git clone https://bitbucket.org/jacobstopak/baby-git.git

If you want to stick with Git's original codebase (without the extensive comments I added), use this command instead:

git clone https://github.com/git/git.git

Browse into the new git directory by running the command cd git. Feel free to poke around the folders and files in here.

You'll quickly notice that in the current version of Git – the version currently checked out in your working directory – that there are a lot of files containing a lot of very long and complicated-looking code.

Clearly this current version of Git is too big for a single developer to realistically get acquainted with in a reasonable amount of time.

Let's simplify things by checking out Git's initial commit, using the command:

git log --reverse

This shows a list of Git's commit log in reverse order, starting from Git's initial commit. Note that the first commit ID in the list is e83c5163316f89bfbde7d9ab23ca2e25604af290.

Check out the contents of this commit into the working directory by running the command:

git checkout e83c5163316f89bfbde7d9ab23ca2e25604af290

This puts Git into a detached head state and places Git's original code files into the working directory.

Now run the ls command to list these files, and note that there are only 10 that actually contain code! (The 11th is just a README). Understanding the code in these files is totally manageable for an intermediate developer!

Note: If you're using my Baby Git repository, you'll want to run the command git checkout master to abandon the detached head and move back to the tip of the master branch. This will enable you to see all the inline comments describing how Git's code works line by line!

Important C Concepts that Will Help You Understand Git's Code

Before diving straight into Git's code, it helps to get a refresher on a few C programming concepts that appear throughout the codebase.

C Header Files

A C header file is a code file ending in the .h extension. Header files are used to store variables, functions, and other C objects that a developer wants to include in multiple .c source code files using the #include "headerFile.h" directive.

If you're familiar with importing files in Python or Java, this is a comparable procedure.

C Function Prototypes (or Function Signatures)

A function prototype or signature tells the C compiler information about a function definition – the function's name, number of argument, types of arguments, and return type – without providing a function body. They help the C compiler identify function properties in situations where the function body appears after the function is called.

Here is an example of a function prototype:

int multiplyNumbers(int a, int b);

C Macros

A macro in C is essentially a rudimentary variable that is processed before code compilation in a C program. Macros are created using the #define directive, such as:

#define TESTMACRO asdf

This creates a macro called TESTMACRO with a value of asdf. Wherever the placeholder TESTMACRO is used in the code, it will be replaced by the preprocessor (before code compilation) with the value asdf.

Macros are commonly used in a few ways:

• As a true/false switch by checking whether a macro is defined

• To store a simple integer or string value to be replaced in the code in multiple locations

• To store a simple (usually one-line) code snippet to be replaced in the code in multiple locations

Macros are convenient tools since they enable developers to update a single line of code which influences the behavior of the code in multiple locations.

C Structs

A struct in C is a grouped set of properties that are related to a single object.

You are probably familiar with Classes in languages such as Java and Python. A struct is a predecessor to a class – it can be thought of as a primitive class with no methods.

struct person {

    int person_id;
    char *first_name;
    char *last_name;

};

This struct represents a person, by grouping together an ID field, along with the person's first and last names. A variable can be instantiated and initialized from this struct as follows:

struct person jacob = { 1, "Jacob", "Stopak" };

Struct properties can be retrieved using the dot operator:

jacob.person_id
jacob.first_name
jacob.last_name

C Pointers

A pointer is a memory address of a variable – it is the memory address at which the value of that variable is stored.

A pointer to an existing variable can be obtained by using the & symbol, and stored in a pointer variable declared with the * symbol:

int age = 21;

int* age_pointer = &age;

This snippet defines the variable age and assigns it a value of 21. Then it defines a pointer to an integer called age_pointer, and uses the & to obtain the memory address that the value of the age variable is stored at.

Pointers can be dereferenced (i.e. obtain the value stored at the memory address), using the * as well.

int new_age = *age_pointer + 10;

Continuing from our previous example, we use the *age_pointer syntax to fetch the value stored in the pointer (21), and add 10 to it. So the new_age variable would contain a value of 31.

Now that our short segue into C programming is completed, let's get back to Git's code.

Overview of Git's Codebase Structure

There are ten relevant code files that make up Git's initial commit. We'll start by briefly discussing these two:

• Makefile

• cache.h

We'll discuss Makefile and cache.h first because they are a bit special.

Makefile is a build file that contains a set of commands used to build the other source code files into executables.

When you run the command make all from the command line, the Makefile will compile the source code files and spit out the relevant executables for Git's commands. If you're interested, I wrote an in-depth guide on Git's makefile.

Note: If you actually want to compile Git's code locally, which I recommend you do, you'll need to use my Baby Git version of the code mentioned above. The reason is that I made some tweaks to allow Git's original code to compile on modern operating systems.

Next up is the cache.h file, which is Baby Git's only header file. As mentioned above, the header file defines many of the function signatures, structs, macros, and other settings that are used in the .c source code files. If you're curious, I wrote an in-depth guide on Git's header file.

The remaining eight code files are all .c source code files:

• init-db.c

• update-cache.c

• read-cache.c

• write-tree.c

• commit-tree.c

• read-tree.c

• cat-file.c

• show-diff.c

Each file (except read-cache.c) is named after the Git command that it contains the code for – some probably look familiar to you. For example, the init-db.c file contains the code for the init-db command used to initialize a new Git repository. As you probably guessed, this was the precursor to the git init command.

In fact, each of these .c files (except read-cache.c) contains the code for one of the original eight Git commands. The build process compiles each of these files and creates an executable file (with matching name) for each one. Once these executables are added to the filesystem path, they can be executed similarly to any modern Git command.

So after compiling the code using the make all command, the following executables are produced:

• init-db: Initializes a new Git repository. Equivalent to git init.

• update-cache: Add a file to the staging index. Equivalent to git add.

• write-tree: Creates a tree object in the Git repository from the current index contents.

• commit-tree: Creates a new commit object in the Git repository. Equivalent to git commit.

• read-tree: Print out the contents of a tree from the Git repository.

• cat-file: Retrieve the the contents of an object from the Git repository, and store it in a temporary file in the current directory. Equivalent to git show.

• show-diff: Show the differences between files staged in the index and the current versions of those files as they exist in the filesystem. Equivalent to git diff.

These commands are executed individually in sequence, similar to how modern Git commands are executed as a part of standard development workflows.

The one file we haven't discussed yet is read-cache.c. This file contains a set of helper functions that the other .c source code files use to retrieve information from the Git repository.

Now that we've touched on each of the important files in Git's initial commit, let's discuss some of the core programming concepts that allow Git to function.

Implementation of Git's Core Concepts

In this section, we'll discuss the following programming concepts that Git uses to work its magic, as well as how they were implemented in Git's original code:

• File compression

• Hash function

• Objects

• Current directory cache (staging area)

• Content addressable database (object database)

File Compression

File compression, also know as deflation, is used for storage and performance efficiency in Git. This reduces the size of the files that Git stores on disk and increases the speed of data retrieval when Git needs to transfer these files across a network.

This is important since Git's local and network operations need to be as fast as possible. As a part of the data retrieval process, Git decompresses, or inflates, the files to obtain their content.

Source: https://initialcommit.com/blog/Learn-Git-Guidebook-For-Developers-Chapter-2

File deflation and inflation were implemented in Git's original code using the popular zlib.h C library. This library contains functions, structures, and properties for compressing and decompressing content. Specifically, Zlib defines a z_stream struct that is used to hold the content that is to be deflated or inflated.

The following zlib functions are used to initialize a stream for deflation or inflation, respectively:

/*
 * Initializes the internal `z_stream` state
 * for compression at `level`, which indicates
 * scale of speed versuss compression on a 
 * scale from 0-9. Sourced from <zlib.h>.
 */
deflateInit(z_stream, level);

/*
 * Initializes the internal `z_stream` state for
 * decompression. Sourced from <zlib.h>.
 */
inflateInit(z_stream);

The following zlib functions are used to perform the actual deflation and inflation operations:

/*
 * Compresses as much data as possible and stops
 * when the input buffer becomes empty or the
 * output buffer becomes full. Sourced from <zlib.h>.
 */
deflate(z_stream, flush);

/*
 * Decompresses as much data as possible and stops
 * when the input buffer becomes empty or the
 * output buffer becomes full. Sourced from <zlib.h>.
 */
inflate(z_stream, flush);

The actual deflation/inflation process is a bit more complex than this and involves setting several parameters of the compression stream, but we won't go into more detail here.

Next, we'll discuss the concept of hash functions and how they are implemented in Git's original code.

Hash Functions

A hash function is a function that can easily transform an input into a unique output, but makes it very difficult or impossible to reverse that operation. In other words, it is a one-way function. It is not possible with today's technology to use the output of a hash function to deduce the input that was used to generate that output.

Git uses a hash function – specifically the SHA-1 hash function – to generate unique identifiers for the files we tell Git to track.

As developers, we make changes to the code files in the codebase we are working on using a text editor, and at some point we tell Git to track those changes. At this point, Git uses those file changes as inputs for the hash function.

The output to the hash function is called a hash*.* The hash is a hexadecimal value 40 characters in length, such as 47a013e660d408619d894b20806b1d5086aab03b.

Source: https://initialcommit.com/blog/Learn-Git-Guidebook-For-Developers-Chapter-2

Git uses these hashes for various purposes that we will see in the following sections.

Objects

Git uses a simple data model – a structured set of related objects – to implement its functionality. These objects are the nuggets of information that enable Git to track changes to the files of a codebase. The three types of objects that Git uses are:

• Blob

• Tree

• Commit

Let's discuss each one in turn.

Blob

A blob is short for a Binary Large OBject. When Git is told to track a file using the update-cache <filename.ext> command, (the predecessor to git add), Git creates a new blob using the compressed contents of that file.

Git takes the content of the file, compresses it using the zlib functions we described above, and uses this compressed content as input to the SHA-1 hash function. This creates a 40 character hash that Git uses to identify the blob in question.

Finally, Git saves the blob as a binary file in a special folder called the object database (more on this in a minute). The name of the blob file is the generated hash, and the contents of the blob file are the compressed file contents that were added using update-cache.

Tree

Tree objects are used to link together multiple blobs that are added to Git at once. They are also used to correlate blobs with file names (and other file metadata like permissions), since blobs don't provide any information besides the hash and compressed binary file content.

For example, if two changed files are added using the update-cache command, a tree will be created containing the hashes of those files, along with the file name that each of those blobs corresponds to.

What Git does next is very interesting, so pay attention. Git uses the content of the tree itself as input to the SHA-1 hash function, which generates a 40 character hash. This hash is used to identify the tree object, and Git saves this in the same special folder that blobs are saved in – the object database we'll touch on shortly.

Commit

You're probably more familiar with commit objects than with blobs and trees. A commit represents a set of file changes saved by Git, along with descriptive information about the change such as a commit message, the author's name, and the timestamp of the commit.

In Git's original code, a commit object is the result of running the commit-tree <tree-hash> command. The resulting commit object includes the specified tree object (which remember, represents a collection of file changes via one or more blobs mapped to their file names), and the descriptive information mentioned in the previous paragraph.

Like blobs and trees, Git identifies the commit by hashing its content using the SHA-1 hash function, and saving it in the object database. Importantly, each commit object also contains the hash of its parent commit. In this way, the commits form a chain that Git can use to represent the history of a project.

Current Directory Cache (Staging Area)

You probably know Git's staging area as the place your changed files go after using the git add command, patiently waiting to be committed using git commit. But what exactly is the staging area?

In Git's original version, the staging area is called the current directory cache. The current directory cache is just a binary file stored in the repository at the path .dircache/index.

As mentioned in the previous section, after changed files are added to Git using the update-cache (git add) command, Git calculates the blob and tree objects associated with those changes. The generated tree object associated with the staged files is added to the index file.

It is called a cache because it is just a temporary storage location for the staged changes to reside before being committed. When the user makes a commit by running the commit-tree command, the tree from the current directory cache can be supplied. It also includes other commit information like the commit message for Git to create a new commit object with.

At that point the index file is simply removed to make room for new changes to be staged.

Content Addressable Database (Object Database)

The object database is Git's primary storage location. This is where all the objects we discussed above – blobs, trees, and commits – are stored. In Git's original version, the object database is simply a directory at the path .dircache/objects/.

When Git creates objects through operations such as update-cache, write-tree, and commit-tree, (the predecessors of git add and git commit), these objects are compressed, hashed, and stored in the object database.

The name of each object is the hash of its content, hence why the object database is also called a content addressable database*.* Each piece of content (blob, tree, or commit) is stored and retrieved based on an identifier generated from the content itself.

The modern version of Git works very much the same way. The difference is that storage formats have been optimized to use more efficient methods (especially related to data transfer over networks), but the basic principles are the same.

Summary

In this article, we discussed the original version of Git's code in order to highlight how reading existing code can help boost your coding skills.

We covered the reasons Git is a great project to learn from in this way, how to access Git's code, and reviewed some related C programming concepts. Finally, we provided an overview of Git's original codebase structure and dove into some concepts that Git's code relies on.

Next Steps

If you're interested in learning more about Git's code, we wrote a guidebook you can check out here. This book dives into Git's original C code in detail and directly explains how the code works.

I encourage any and all developers to explore the open-source community to try and find quality projects that interest you. Those projects will have codebases that you can clone down in a matter of minutes.

Take some time to poke around the code, and you might learn something you never expected to find.

I'm interviewing my colleague Lennart Frantzell, a fellow developer advocate on the IBM Developer San Francisco team. Inside IBM, Lennart focuses on one of our most technically in-depth communities: Blockchain.

Q: Your developer advocacy efforts focus on projects with large codebases and technical architectures that requires developers to adapt their mental models. Can you tell us about them?

When I came to Silicon Valley in the late 80s I worked on one of the most exciting projects imaginable, Expert Systems, the precursor to today's AI systems and IBM's Watson project. I spend four years in Menlo Park in the childhood of Silicon Valley creating language compilers with built-in AI capabilities. As often with leading-edge technology, we didn't quite make it. Fortunately I then had the opportunity to work on a team in IBM's Silicon Valley Lab in southern San Jose that took prototypes from IBM Research and productized them. From there I moved to Object Oriented systems and have really always worked on advanced software systems. Some of which succeeded but many of which did not. Just like in the start-up world.

Q: How did you get started with programming?

Originally I was majoring in Asian Studies in Sweden and I received my doctorate from the University of Stockholm. After graduation, I realized that there were no jobs in my chosen field, and I began to take an interest in computers. I took a few courses and landed a job in the IT department of the food chain Shoprite on the East Coast of the US. Two years later IBM was advertising for a job for something called the Series/1 minicomputer, which we used at Shoprite. I was lucky to be accepted and spent the next four years writing assembler code that automated telephone switches in Seattle, which I fell in love with. And which is the reason that my oldest son with his family now lives and works in Seattle.

IBM Series/1 Minicomputer

Q: How did you make the transition from programmer to developer advocate?

I have always loved programming but I have also liked working with people, and when I got the opportunity to jump over to one of IBM's Innovation Centers and work with business partners I didn't hesitate.

After a few years this led me to Developer Advocacy which is really great because one meets so many developers and start ups from various geographies and countries with their own perspective on technology.

Q: How do you find that advocacy for deep technical projects differs from developer advocacy in general?

IT technology is suddenly eating the world as Marc Andreessen has pointed out. It is no longer a peripheral technology but changing society all around us.

One compelling example is AI, with image recognition and facial recognition. We have made amazing strides with increased image recognition capabilities, but it turns out there is a flip side to these advances: do we really want AI-systems that can trace our every step. This is something that we as developer advocates can highlight and make people and ourselves aware of.

There is code but code also has a social impact, both good but also from time to time negative.

I enjoy putting together events that focus both on the technical but also on the social aspects of technology. I enjoy looking at the big picture, and it's exciting to work at a company like IBM that gives me free rein to work with developers and startups and not always follow a specific corporate line.

Q: How do you get introductory programmers interested in a deep or very technical ecosystem?

Start with the impact on society. I get uneasy when I encounter people who may not see the forest for the trees, i.e. the impact their code may have on society.

I should also mention the IBM Code Patterns -- an innovative approach to providing developers with working code around specific themes. They allow us to quickly get developers up and running in areas such as AI, Blockchain or Machine Learning, to name a few areas. Something that makes our job a lot simpler than before and that allows us and the people we talk to to quickly see how new technology is behaving in real life.

Q: What technologies that you’ve worked with are you most excited about?

Blockchain, Machine Learning and AI. These technologies are where the future is, and that are already an important part of our society.

For instance, a self-driving car is something you wouldn’t even imagine a few years ago, and now we’re talking not only about the underlying technology and algorithms, but also the impact on society and the freedom it can bring to people around the world.

Q: Let's talk logistics. What types of events tend to work well for the tech you’re advocating?

Face to face events with between 50 and 100 people present. You must remember that attendees come to these events to mingle. They want to meet people, talk, exchange opinions -- they’re not really interested in listening to us talk for an hour or longer. All information is usually out on the web anyway.

They want to learn and code, sure, but it’s primarily a social event and they want to mingle and get contacts. Being able to read the audience and respond to what they want is an important skill as a developer advocate.

Also, we do a lot of hackathons, which are essentially long-running social events. I love working on hackathons more than almost anything else.

Q: Any best practices in developer advocacy that you’ve been exposed to?

I just went to DevRelCon SF 2019 and you could tell from the presentations that developer advocates as a group are really good at talking to an audience -— especially when they are talking about themselves!

Dana Oshiro from Heavybit gave a great talk at DevRelCon SF 2019. It was very factual, and not specific to developer relations but about different aspects of company fundraising, board dynamics and cashflow that are relevant to advocacy but that many advocates may not be exposed to.

Dana Oshiro speaks at DevRelCon SF 2019

Q: What do you want to learn, and who do you want to meet or partner with?

I want to spend time combining Blockchain, AI, ML and IoT, and see where that will lead. It would also be interesting to spend more time with larger startup companies who are on the way to building enterprise applications — currently, I spend a lot of time with smaller startups and individual developers, but working with larger companies will give you a more holistic view of what companies are trying to build with IBM Cloud-technology, including Blockchain and AI. I’m not working in that space currently but I am hoping to get into it very soon.

To get in touch with Lennart, feel free to reach out on LinkedIn: https://www.linkedin.com/in/lennartfrantzell/

Outreachy gives three-month paid internships for persons that are underrepresented in tech. Interns are paid a stipend of $5,500 and have a $500 travel stipend available to them.

Outreachy interns work remotely with mentors from Free and Open Source Software (FOSS) communities on projects for programming, user experience, documentation, illustration and graphical design, and data science tasks.

I participated in Outreachy round 14 from May through August 2017 with Ceph. I was working on expanding S3 testing for Ceph’s Rados Gateway. This opportunity changed my career for the good. From starting me working with open source to making me a confident engineer — and giving me the platform to many job opportunities.

_Image from [Planet Outreachy](https://www.planeteria.info/outreach/" rel="noopener" target="blank" title=")

The Outreachy internship applications open twice a year — in February for the May through August — in September for the December through March cohorts.

Well, like me during my application process, you are probably wondering “How do I ace this?” if you are an applicant. From some direct messages and pings I have gotten on this in the past, I will share some thoughts.

The process

Before I share my thoughts on how to go through this process, I will point out a disclaimer. These thoughts are not a guarantee that you will get in, they are just guidelines that could help you in my opinion.

Before you get lost in the so many details in this article, applying for an Outreachy internship is a very engaging process. It requires you to make many decisions and to commit the effort of making contributions as part of the requirements to be accepted.

To get the most of your application process, you need to ensure:

• You Start Early
• Narrow down your project choices to two at the most
• Set your goals
• Engage with the community and project Mentors frequently
• Focus on progress not perfection
• Remember the process is much more important than the outcome

Let me elaborate on these.

Start Early

One of the things you need to do is not procrastinate till like a week before the deadline. The application process is engaging. You need to start the process early so that the project mentors and community get to know and interact with you and the magic you can do early in the process.

If the mentors get to know you early and longer, then their decisions to choose you will be more informed than if you come in days before the deadline.

Narrow down your project choices

Outreachy usually has a list of organizations and most of them have interesting projects you would love to work on. In fact, when I was applying for my Outreachy internship I wanted to be everywhere. But you can’t be. That is the fact and if you do try to be everywhere, your chances of getting accepted become few.

The reason you need to focus on a few projects is that this will enable you to concentrate on being a great candidate for that project. It means you will spend more time understanding the project, communicating with the mentors, and in turn making significant contributions to the project — as opposed to being everywhere and achieving half-baked progress on many projects.

Set some goals

After you have selected what projects you want to apply to, you will reach out to the mentors for guidance on first time tasks to work on — or you can look at the project’s issue list for potential tasks. Set some goals for what you want to work on and what kind of candidate you want to be known for.

For example you could say “I want to make 5 contributions for my application process and have a good proposal”. With your own goals, you won’t fall prey to unnecessary pressure. This shouldn't be a competition with other applicants. With your set goals, you are competing with your own goals and no one else.

Engage the community and project Mentors frequently

One of the ways you will get to understand the project and get more help on the task you are doing is by talking to the project mentors and community frequently.

This makes you get used to working with the mentors and community early because during your internship you will need to do this. Discuss what you are about to work on, what you are working on and even discuss the patch. This gives the impression that you know what you are doing but also helps you get feedback early enough.

Ask questions when you are stuck, open source projects are worked on as a community. There is no need to die with a blocker.

Tasks are not meant to kill people but there should be a balance between you finding a way of solving some problems independently as well.

Do some homework before asking, do some research on the subject before asking. If you fail to get a solution, then engage your mentors as soon as possible. Challenges keep us motivated to work on a daily basis, so try that challenge and then ask your mentor. Do not spend 2 hours on a blocker, just reach out.

Progress not perfection

When you are given a task, you may get tempted to go hide yourself in the basement so that you come up with a solution a week later with all its glory, unit tested and whatever you think in your head is the best solution to the task.

The focus is to commit early, and get feedback as early as possible so that you get a patch merged in the shortest time possible. Patches become perfect only after being committed. It is the feedback that we get from reviewers and community that makes patches perfect. Therefore, quit the basement and work with the community.

Discuss the internship project with mentors

There is usually a project you will be working on that you won’t start until you are accepted to be an Outreachy intern. As you make contributions, create some time to discuss the milestones of the project that you will be working on, if you are accepted, with your mentors. Let your mentor advise you on scope and time lines.

This will inform you on how to create a time line when you are filling in the Outreachy application form. You will fill out this form with an informed mind on the project tasks and this is a plus when they are assessing you.

Also, ask for feedback on the proposal/application form contents before the deadline. Feedback will always make anything you work on better.

The process is much more important than the outcome

The tough truth to your Outreachy application is either you were accepted or you were not accepted to this round of Outreachy. I have had the chance of knowing how both decisions feel.

Now let me tell you something, the real beauty about Outreachy is the process.The first time I applied to Outreachy I didn’t get in.

But I learned Golang. I used that skill on my next project. I was accepted the second time and now I work on a couple of Go projects. Maybe this is not convincing enough.

I applied to an organization that did not accept me. But from the tasks I worked on with Python compatibility, I got inspired to write my first book about Python 2 and 3 Compatibility. Due to the scarcity of material on the subject, Apress gladly accepted it for publishing.

The application process should be attempted by everyone. Whether you get in or not, it is always a win. You will have made contributions to a project that will act as your project references for your next opportunity.

You will have started yourself in open source if you are a beginner to FOSS. The FOSS mentors are always willing to guide you should you want to continue with contributing.

You will have been introduced to and learned from the best and most welcoming people in this tech industry to prepare for your future opportunities.

If you forget anything here, don't forget the fact that applying to Outreachy is always a win, accepted or not. And do not forget to apply again in the next round. If you fail — keep trying till you get in.

Good luck to everyone applying!!! May the force be with you. As always ping me if you have any questions.