Open source software is everywhere. Whether you use an Android phone, a Chromebook, or web-based applications like Gmail and Google Docs, online code is part of your everyday experience. In recent years, large companies like Amazon, Facebook, and Google have embraced the open source development model due to its collective nature. Many large companies now share their code with the rest of the world while they continue to maintain ownership.
Linux is a great operating system. It is open source and, in many ways, provides a far better user experience than the famously popular Windows OS by Microsoft. Linux has managed to establish a loyal following among both desktop and server users. Linux enjoys widespread adoption in data centers, cloud computing and web applications. In fact, Linux supports more web servers, supercomputers, and has been ported to more computer architectures than any other operating system in history. This article will teach you how to open soource code in linux and how to use it:
Getting the source code from GitHub
Like many open-source projects, the sources of NodeJS can be found on GitHub: https://github.com/nodejs/node
So, let’s go directly there.
If you’re not familiar with GitHub, git or any other version control system worth mentioning the repository contains the current source for the software, as well as a history of all the modifications made through the years to that software. Eventually up to the very first line written for that project. For the developers, keeping that history has many advantages. For us today, the main one is we will be able to get the sources from for the project as they were at any given point in time. More precisely, I will be able to get the sources as they were when the 8.1.1 version I want was released. Even if there were many modifications since then.
On GitHub, you can use the “branch” button to navigate between different versions of the software. “Branch” and “tags” are somewhat related concepts in Git. Basically, the developers create “branch” and “tags” to keep track of important events in the project history, like when they start working on a new feature or when they publish a release. I will not go into the details here, all you need to know is I’m looking for the version tagged “v8.1.1”
After having chosen on the “v8.1.1” tag, the page is refreshed, the most obvious change being the tag now appears as part of the URL. In addition, you will notice the file change date are different too. The source tree you are now seeing is the one that existed at the time the v8.1.1 tag was created. In some sense, you can think of a version control tool like git as a time travel machine, allowing you to go back and forth into a project history.
At this point, we can download the sources of NodeJS 8.1.1. You can’t miss the big blue button suggesting to download the ZIP archive of the project. As for me, I will download and extract the ZIP from the command line for the sake of the explanation. But if you prefer using a GUI tool, don’t hesitate to do that instead:
wget https://github.com/nodejs/node/archive/v8.1.1.zip unzip v8.1.1.zip cd node-8.1.1/
Downloading the ZIP archive works great. But if you want to do it “like a pro”, I would suggest using directly the
git tool to download the sources. It is not complicated at all— and it will be a nice first contact with a tool you will often encounter:
# first ensure git is installed on your system sh$ sudo apt-get install git # Make a shallow clone the NodeJS repository at v8.1.1 sh$ git clone --depth 1 \ --branch v8.1.1 \ https://github.com/nodejs/node sh$ cd node/
By the way, if you have an issue, just consider the first part of this article as a general introduction. Later I have more detailed explanations for Debian- and RedHat-based distributions in order to help you troubleshoot common issues.
Anyway, whenever you downloaded the source using
git or as a ZIP archive, you should now have exactly the same source files in the current directory:
sh$ ls android-configure BUILDING.md common.gypi doc Makefile src AUTHORS CHANGELOG.md configure GOVERNANCE.md node.gyp test benchmark CODE_OF_CONDUCT.md CONTRIBUTING.md lib node.gypi tools BSDmakefile COLLABORATOR_GUIDE.md deps LICENSE README.md vcbuild.bat
Checking Out a Project
Once you have an account you can dive straight into an open source application found on GitHub. Here you can see the application’s project page, including folders and files pertaining to the application, a network graph, a list of pull requests, open issues, a wiki, and other graphs. Obviously, if you want to see the code within the files, you should click on them and you’ll be presented with the full source code. As far as interpreting the code goes, you’ll need to have some background in the programming language that the application is written in, whether it be Java, C++, Python, or something else. For those wondering, the screenshot shows Caleb Evan’s jcanvas project.
Understanding the Build System of the program
We usually talk about “compiling the sources”, but the compilation is only one of the phases required to produce a working software from its source. A build system is a set of tool and practices used to automate and articulate those different tasks in order to build entirely the software just by issuing few commands.
If the concept is simple, the reality is somewhat more complicated. Because different projects or programming language may have different requirements. Or because of the programmer’s tastes. Or the supported platforms. Or for historical reason. Or… or.. there is an almost endless list of reasons to choose or create another build system. All that to say there are many different solutions used out there.
NodeJS uses a GNU-style build system, it is a popular choice in the open source community and once again, a good way to start your journey.
Writing and tuning a build system is a pretty complex task, but for the “end user”, GNU-style build systems ease the task by using two tools:
configure file is a project-specific script that will check the destination system configuration and available feature in order to ensure the project can be built, eventually dealing with the specificities of the current platform.
An important part of a typical
configure job is to build the
Makefile. That is the file containing the instructions required to effectively build the project.
make tool, on the other hand, is a POSIX tool available on any Unix-like system. It will read the project-specific
Makefile and perform the required operations to build and install your program.
But, as always in the Linux world, you still have some leniency in customising the build to your specific needs.
configure -help command will show you all the available configuration options. Once again, this is very project-specific. And to be honest, it is sometimes necessary to dig into the project before fully understanding the meaning of each and every configure option.
But there is at least one standard GNU Autotools option that you must know: the
--prefix option. This has to do with the file system hierarchy and the place your software will be installed.
Forking a Project
Editing the code requires some additional steps. If you wish to copy the code without officially forking it on GitHub, you’ll need to download the project’s files and then edit them locally on your computer. However, if you’re truly looking at using the currently available source and creating your own project with it and going in your own direction, you’ll want to fork it. Forking can be accomplished with an account, and by clicking on “Fork” on the project’s page as shown in the screenshot. The next few instructions are for Linux users who should install the G
package for their respective distribution.
If you wish to retrieve the repository’s files to your computer, you’ll need to run the command
git clone https://github.com/username/project_name.git
, replacing username with your GitHub username and project_name with the name of the application project that you just forked. Run this command within a folder that should contain all of your GitHub projects, as each git clone command will create a new folder within the one you’re currently residing. This is another way of downloading a project’s file as it doesn’t require login credentials. Now you can change the files as you please using any text editor or IDE. For Linux users, I’d recommend Eclipse or Geany as they’re great programming editors — Eclipse being more full-featured and Geany being leaner. Windows users can also use the native GitHub client.
How to Use Open Source Software Wisely
Open source software is everywhere. And using open source repositories could help you accelerate development and reduce costs.
But how do you do it without risking the drawbacks?
It’s definitely possible. If you follow the right steps…
1. Find a Sound Project
Open source projects are not created equally. Some projects will be more reliable than others. And there are tons of options to consider for every type of open source component. For instance, GitHub alone has over 100 million repositories created by 31 million contributors.
As you evaluate potential code to leverage, ask the following questions:
- Who created it?
- Is it actively developed?
- Is it maintained?
- How often has it been downloaded?
Popularity indicates quality — and applicability of open source. If a project is popular (and has many contributors), it will likely have what you need for your own project.
Some projects are universal. Big name companies (Facebook, Google, Microsoft, Netflix) all have created popular open source projects. These become so popular that developers almost forget where they started.
2. Check the License Before You Use It
There are different types of licenses for open source projects. After you select a project, be sure to read the fine print. That way, you’ll know what exactly you’re signing up for — and avoid any potential violations/lawsuits.
3. Vet Security — Beyond the Community
Before you use open source components in your proprietary software, you need to know it won’t cause security risks. Selecting with an open source project with an active support community helps. That community can alert you to any security issues.
But the best way is to do security checks up front. Using a static analyzer can be useful here to identify potential errors (such as buffer overflow) that lead to security risks.
It’s also important to ensure security as you bring the code into the build. For example, if you use Jenkins, you can mirror or populate open source Git code into Helix4Git. That allows you to control the code more closely. Then you can execute security tests at appropriate stages of the pipeline.
4. Stay on Top of Updates
Any time the open source components you’re using get updated, you’ll need to ensure they still work properly with proprietary components. Staying on top of updates is key to avoiding issues.
Managing the code in a tool like Helix4Git gives you more control over when and how you adopt it into your product.
If you are interested in learning more about source code, you came to the right place! Open source software is not just for programmers; it includes projects for writers, architects, engineers, and many other creative types. In this tutorial, we will explore what these programs have in common and then demonstrate how you can use them for your next project.