An Overview of the Open Source Software Ecosystem
Try reloading this page, or reviewing your browser settings
While, technically speaking, ‘open source’ refers only to how software is licensed, you can nevertheless observe several features common to a great many open source projects, especially development methods and tools. This video segment describes those basic practicalities of how open source software is typically developed.
- issue tracker
About this video
- Karl Beecher
- First online
- 03 December 2018
- Online ISBN
- Copyright information
- © Karl Beecher 2019
Karl Beecher: Technically speaking the core concerns of Open Source Software are to do with licensing and distribution, questions concerning which terms are granted to the end user, and to what extent those rights are protected. Open Source Software doesn’t enforce any particular method for how programs are written. There’s no open source fixed to develop a model. However, if we examine a lot of open source projects, you’ll discover common patterns and techniques echo across the whole ecosystem. This segment will describe some of those in more detail. So let’s begin at the beginning and ask the question where does it all start? Where do open source projects come from? It was once remarked that good open source programs frequently come into being because they scratch an itch. That’s to say somebody somewhere has a need that the current body of software can’t satisfy leading them to invent the software it does.
There are several different types of itch that could come about. First, the program doesn’t already exist. A pretty straightforward motivation to write a program, you want something that performs a particular function but nothing else available suffices, so you’ll write one that does. The point at which the program becomes Open Source Software varies. For example, the program could be written by a single person who originally gave no thought to distributing the end product. Equally the program could be written by a team with a large company who develop the program at Open Source Software for strategic purposes from at the very inception. Why a company may wish to do that is something we’ll explore in the later video. Because the existing non-free version doesn’t do what you want or is faulty.
In this situation, a user has few option beyond asking the vendor for changes and then waiting and hoping. But a user with programming skills could do better than that. They could develop their own version of the program with the missing features or minus the annoying bug. Because the existing open source version can’t or won’t incorporate your improvements. The user of an open source program can add improvements on new features to their own copy of the program whatever they desire. If they wish to share their work with others, there are a couple of ways they can do it. The standard way would be for the user to submit their changes back to the project owners and have them incorporate it into the project. However the project owners owned no obligation to accept.
They may not like the changes, perhaps judging them unnecessary or shortly done for example or they may feel the changes would take the project in the wrong direction. In this case the user could decide to release the changes themselves producing a new version of the program that incorporates the changes. This approach is called forking. But it is generally looked upon as a last resort option and is rarely undertaken. Simply for the challenge or satisfaction. Some programmers just like to code for the fun of it or create a program a learning exercise. Many such projects never see the outside of the author’s hard drive but some have flowed into successful projects. In fact, we have to Linux operating system partly because its creator, Linus Torvalds, wanted to learn about the features of his new CPU and so he wrote Linux as a hobby.
Now in each case, if the developer identifies a need for what they produce, they can decide to attract others to help om writing it by sharing the source code with them. There’s not a notable way in which Open Source Software comes about which is relicensing. In this case, a program might begin as non-free software but the owner then decides to relicense it for distribution under an open source license. Numerous projects have undergone this. For example, open office which used to be the proprietary StarOffice and the Java programming language that used to be distributed under proprietary terms. Once an open source project is started, where is it? Where does it live and how was it developed? Let’s examine some of the typical tools and techniques.
Since the whole idea of Open Source Software is that users can make changes to the program and contribute those changes back, an open source project needs infrastructure to support that way of working. So an open source project, usually but not always, lives online, accessible via the internet. This allowed it to be developed in a distributed manner. People working on open source project might occupy the same building or they might live on opposite sides of the world. Often that project resides in an online hosting service. A web based application is designed to support distributed software development. Hosting can be done by a third party. For example, GigHub, Bitbucket, SourceForge, just to name a few. These are commercial services that will store your code and provide convenient ways to access it via the web. They often provide tiered services, basic functionality free of charge, and more sophisticated packages for a fee.
If you prefer, you can host the project yourself with your own website. For that, you’ll need a repository management tool to support your development activities. As usual, the open source community provides you with several options. Examples include GitLab or Redmine. Whether your project hosting service is self-hosted or third party, open source projects typically require a core set of features for the service in order for the work to get done. The rest of this video segment will describe those tools. Before we look at them, keep in mind that these tools and techniques are not exclusive to open source development. Plenty of closed source projects use them too. Neither is it the case that all open source projects use all of them. Each project is different. What follows is just a typical basic set up you might expect to encounter.
The source code itself resides in the source code repository, which you might consider the canonical version of the program. It also acts as an audit service maintaining a history of every change made including the date and time and the person responsible. A user could download a copy of the code from the repository to their home computer where they can make changes to that local copy. If they wish, they can offer to incorporate their changes into the canonical version by uploading a patch which is a description of the code changes. The project administrators can review the patch and decide either to reject it or apply those changes to the code in the repository. To support all this work on the code, several tools exist for the necessary coordination. One is traditional email. And this still performs a vital role in allowing project members to communicate.
And while email is fine for asynchronous communication, it also needed for real time, quick and easy communication, which is often fulfilled by a messenger app. Many projects allow visitors to join their messenger areas and participate in conversations, so you can easily get to know the very people who are developing the applications you use. An issue tracker supports many management duties. A trucker keeps a collection of records, each one a discrete actionable task. Bug reports, test descriptions, feature requests, and so on. Each one has a status, new, in progress, waiting review, etcetera, and developers can add comments providing for discussion and an order trail. Finally a means of documenting work is provided by a wiki, the collaborative documentation system. A wiki for an open source project, it often divided to areas. Typically areas include user documents. That’s manuals, tutorials, etcetera.
Technical documents that’s descriptions of the project for people wishing to develop the system. And administrative pages which record decisions, meetings, release plans, and so on. So that’s an overview of a typical open source projects. The next segment, we’ll look at things on a broader scale. The entire Open Source Software ecosystem.