A brief history of Open-source Software and how you can be part of the action

The journey

In the 1950s and 1960s, computer systems came bundled with source code that had to be compiled. Because of the high acquisition and operation costs of computers, only universities and large companies could afford them. These same entities had the resources to find and fix bugs in the code and add functionality to meet their needs. Rather than keep these changes close to their chests, a sense of community emerged wherein the source code with code adjustments was shared with others. The idea lies in the sharing of knowledge.

As the number of users and the contributions increased, it became necessary to catalogue and coordinate these contributions, and repositories were created. These repositories allowed users to search for code that added new functionality or corrected a bug. The community would iteratively take the code and compile it on their systems. If they improved the code, they would upload these improvements to the repositories, benefiting others. Placing code in the public domain operated on the concept of fixing and improving forward. The ARPANET, the precursor of the internet, made it easier to interact with repositories.

In the 1970s, the software landscape changed. The cost of computer hardware was coming down, and therefore the cost to write and maintain software represented a larger percentage of the overall cost of a computer system. In 1969, the US government filed an antitrust suit against IBM in which it alleged that IBM’s bundling of software with “related computer hardware equipment” for a single price was anticompetitive. In 1970, AT&T bundled Unix with its computers but prohibited the distribution or modification of the code. At the same time, software companies whose revenue stream was based solely on software started becoming predominant, and their licensing model prohibited copying and sharing software. Microsoft’s Bill Gates “An Open Letter to Hobbyists,” published in the Homebrew Computer Club, summarises the feeling of software companies towards sharing (pirating) software.

To increase revenues, software companies started distributing the executable version of the software rather than the source code. The source code that only the organisation that created it can modify is called “proprietary” or “closed source” software.

Richard Stallman felt that this was ethically wrong because it prevented others from studying and learning from the code. In 1983, he founded the GNU Project to give users freedom and control by collaboratively developing and publishing software that gives users rights to freely run the software, copy and distribute it, study it, and modify it. He established the Free Software Foundation (FSF) and coined the term copyleft to support GNU and its licence.

In 1997, Eric S. Raymond and the hacker community started pushing the concepts of free-software principles into commercial software, thereby encouraging companies to share the source code of their commercial software. They felt that FSF’s models and how it projected its ideas discouraged commercial companies from considering this model. Their timing was just right; they were active at the peak of the dotcom boom, and Raymond’s writings focused on the economic gains that open source represented. He pointed out that companies like Amazon, Yahoo (both founded in 1994), and other startups were using free software for their operations, and software companies that release their software as open source could make money off it. In 1998, Netscape released the source code of their browser as open source.

Open-source licences

The open-source landscape is dynamic. Proof of this is the number of open-source licences that exist. The open-source initiative lists just under 100 active licences. Broadly speaking, open source covers areas such as:

• Rights of the modified work: Copyleft binds a programmer with the same conditions they were granted on the software they modified or improved; Permissive places minimal restrictions on how others can use open-source components.
• Whether the source or author(s) of the derived work need to be attributed to the derived work
• Use of derived work. Licences can restrict this to specific use-cases or entities.
• Whether the unlicensed (free) software can be used in production environments
• Liability, warranty, and trademark

You and Open source

Simply using open-source software could be your only connection to the movement. These days, a lot of closed-source software uses open-source libraries. It’s possible that you aren’t even aware that the software you use is either open source or depends on it.

For the services and goods they offer, cloud service companies like Amazon AWS, Microsoft Azure, or Google Cloud rely on open-source initiatives. These cloud providers now provide paid services based on open-source products. eBay, Amazon, Airbnb, Facebook, YouTube, Twitter, Reddit, Instagram, and Wikipedia and their competitors would not exist as we know them without open-source products that are core to their operations.

Not all open-source projects look for community volunteers. Even though they offer their solution to anyone, some for-profit firms provide value-added services to paying customers. Some companies feature a community edition of their software where they consider user recommendations. On the other hand, a lot of open-source projects depend on the help of volunteers who give their free time and skills to advance the project.

Joining an open-source project

Here are a few tips that could guide you:

1. Absolute beginners are welcome.

Many people incorrectly think that open-source contributions require people who are technical geniuses or who need to come from an engineering background. Open-source projects rely on people from different backgrounds pooling talents, cultures, opinions, and visions for the advancement of the project.

2. Choose the open-source project you want to associate with.

Are you into office productivity tools, music, video, data analysis, games, utilities, or libraries? Do you prefer a project that is still small with a dozen contributors or an established project with hundreds of active contributors? Would you like to make a project available on another platform? Have you been curious about how image-generation AI software works? Would you like to propose a new function for an existing project? Is there a particular development environment you would like to write in?

3. Projects are not only coding.

Projects require multiple talents to succeed. Interface designers, translators, social media people, testers, documentation maintainers, people to teach others, and people to manage forums are a few of the tasks that make a project successful.

Is there a skill you would like to improve, or are you out to explore something completely new?

Onboarding

Having found an open-source project that interests you, the next step is to get involved. The following tips will allow you to reach your end goal:

• Read, learn, and understand.

While there are hundreds of open-source efforts, they all have their own distinct method of operation and community. Learn more about the project, download the executable (if the project has one), use the software, and join the group’s forum.

Open-source projects are normally very tolerant but will not necessarily spoon-feed you. Sometimes a reply to your question will be a link to a guide. A prospective contributor who floods a forum with questions they could have been answered by simply reading the FAQ will generate lashbacks, especially on large projects.

Once you have an overview of the project itself, check if there are dedicated sub-forums, Discord servers, or mailing lists focused on the type of activity you want to focus on. (Small projects might not be so specialised). With a little bit of perseverance, you will see that topics start becoming clear, and your participation and involvement will gradually start earning you the respect of the community.

Time you invest just observing is time well spent.

• Learn how to use the tools that allow you to contribute to the project.

Many projects use a tool for version control and collaboration among contributors. The project will have its own documentation tools and methodology. Learning how to use these tools is critical to having one’s contributions considered.

Forums could have established policies on how queries are handled. For example, rather than repeating an answer to a question that was previously asked, the response would include a link to the original answer.

Social media postings could require certain hashtags to always be included.

• Chain of command.

Be respectful, discuss, but don’t belittle, and always remember that projects are not necessarily democratic. There are elders and elite individuals who have more clout and say than others.

The upper echelon comprises contributors who have the depth of understanding and vision of where the software should head. They are the gods of these projects. They have seen many cowboys come and make a lot of enthusiastic noise, only to disappear a few weeks later.

There have been instances when differences in the direction result in a splinter group forking the project and starting their own independent development. Trying to be a revolutionary two weeks after you first appeared in a project is unlikely to work.

Perseverance

Those who persist will find that their new hobby has given them new skills, new friends, and the incredible feeling that they are contributing to something greater than they could have achieved on their own. Thomas Fowell Buxton’s quote, “With ordinary talent and extraordinary perseverance, all things are attainable,” nicely summarises what makes open-source projects possible.