Open Source is a decentralised software development model focused on public collaboration. At large, the terms referred to any form of public access to the source material of a particular product design. It embeds ideas of open exchange, community-driven development, public governance and, of course, public access to and distribution of the source material. While it is still mainly present in the software industry, the term 'Open Source' extends to other engineering areas and sciences such as electronics, automotive, robotics and medicine.
For the rest of this unit, we will mainly discuss Open Source in the context of software engineering. Open-source software is, therefore, software in which source code is publicly available. It can be used, enhanced, shared and modified under specific conditions. This approach contrasts with the more traditional, proprietary software development methods. Nowadays, we often talk about closed-source software when referring to proprietary software.
While publicly available, open-source projects cannot generally be modified by just anyone. Projects are typically safeguarded by teams of maintainers whose role is to not only develop the project further but also to assess and manage contributions made to the project. Maintainers are typically the main contributors to open-source projects. And they define the framework for contributing to it. Many times, maintainers themselves have a direct interest in the project for their business activities, and they see Open Source as a way to enhance or accelerate the project's development.
The exact origin of Open Source is unclear. However, while the sharing of source code started in the very early days of the Internet, the term Open Source was coined around 1998 by Christine Peterson, a member of the free software movement back then. At the time, many people in the software industry were already talking about free software -- or freeware. Yet in English, the word 'free' presents an ambiguity: does it refer to cost or liberties? Is it free, as in "free of charge" or as in "free will"? In fact, Open Source means neither. At least, it doesn't necessarily imply one or the other. 'Open Source' is a direct reference to how the source material is accessible in the open. Yet, it doesn't specify usage conditions, like whether the software can be used free of charge.
Indeed, while most open-source software is free to use, some require a paid license for commercial applications. Others may ask for royalties from the revenue generated by any commercial usage. For example, the latter case is seen in game-engines -- software platforms used to create video games. Game engines Unreal Engine will charge their most successful users a royalty from the game they have published and built using their platform. Unity, in a similar fashion, offers a subscription model with different price tiers based on the games' success. In exchange, they grant full access to the entire engine's source code. As we'll see shortly, this gives game engines an immense innovation advantage as they benefit from the work of video game companies, sometimes improving the engine for them in response to specific needs.
Nevertheless, when it was being theorised, the exact sense of Open Source did not make unanimity. Movements such as the Free Open Source Software movement (FOSS) initiated by Richard Stallman remained attached to the word 'free' in the sense of liberty. The FOSS movement believes that once acquired -- free of charge or not -- users should be free to run, copy, distribute, study, change and improve software. FOSS articulates its definition of "free software" around four essential freedoms:
- The freedom to run the program as you wish, for any purpose;
- The freedom to study how the program works and change it so it does your computing as you wish;
- The freedom to redistribute copies so you can help others;
- The freedom to distribute copies of your modified versions to others.
Source: GNU - What is Free Software
The FOSS movement is thus a more radical branch of what we call Open Source today. Open Source at large is more nuanced on the matter. Permissions are granted according to the terms of an open-source license.
Every open-source software is licensed under the terms of an open-source license. A license serves multiple purposes. First, it protects the authors and contributors of open-source software by typically limiting the liabilities and warranties coming with the software. Open-source code is often provided "as-is", and inspecting any code included as part of a larger work is highly recommended. Second, it protects the users of open-source software by granting them explicit permissions and rights without legal repercussions.
Hence, a license usually specifies elements around three core axes:
- Permissions are rights granted to the user by the license. This typically covers commercial usage, distribution, modification, patenting and private use;
- Conditions specify under which terms are the aforementioned permissions granted;
- Limitations cover liabilities, warranties and trademark uses.
Besides, licenses usually fall into two categories: copyleft and permissive.
Copyleft licenses ensure that the license is preserved through modified work. They ensure that new work remains open-source under the same conditions as the original work. Said differently, it isn't possible to add restrictions when redistributing the software. Yet, copyleft is also a spectrum. Strong copyleft licenses like GNU GPLv3 enforce that any modification or larger work is distributed in an open-source fashion and using the GNU GPLv3 license. In this context, larger work means any new software built using an open-source component. It could designate another library or a commercial application that relies on open-source components.
GNU LGPLv3 is slightly more flexible and only enforces a copyleft on libraries. Any other larger work made using GNU LGPLv3 may be distributed under different terms and conditions. Yet, new software libraries -- that is, reusable chunks of codes -- must be made public and licensed under GNU LGPLv3.
Finally, the Mozilla Public License 2.0 -- or MPL-2.0 in short, is a weak copyleft license. It enforces that any modification to an existing open-source file must be released publicly and licensed as MPL-2.0 or a stronger copyleft license such as GNU LGPLv3 or GNU GPLv3. It thus protects the original source code and ensures that what was created in an Open Source fashion remains Open Source. Yet, it is far more flexible regarding larger work constructed from it, libraries or not.
Permissive licenses differ in the permissions they provide and in the conditions they require for modifying source code and distributing it through a larger work. Hence, the Apache 2.0 license demands that any modification to a licensed code be thoroughly documented, contrary to MIT, which doesn't have such a requirement.
Regardless of their nature, copyleft or permissive, every open-source license will require that any code licensed by them is distributed with a proper license notice explicitly stating under what license they are distributed. Some, such as GNU GPLv3, GNU LGPLv3 and MPL-2.0, even enforce the source code availability when the software is distributed. Interestingly, this is not the case with Apache 2.0 and MIT which do not necessarily require the source code to be public when distributing software.
We've summarised this information in the following table to make it more digestible. An interactive version of that table is also available on choosealicense.com.
| License | Permissions | Conditions | Limitations |
|---|---|---|---|
| GNU GPLv3 | ✓ Commercial use ✓ Distribution ✓ Modification ✓ Patent rights ✓ Private use |
✓ Disclose source ✓ Include notice ✓ Same license ✓ Mandatory changelog |
x Liability x Warranty |
| GNU LGPLv3 | ✓ Commercial use ✓ Distribution ✓ Modification ✓ Patent rights ✓ Private use |
✓ Disclose source ✓ Include notice ✓ Same license (library) ✓ Mandatory changelog |
x Liability x Warranty |
| Mozilla Public License 2.0 | ✓ Commercial use ✓ Distribution ✓ Modification ✓ Patent rights ✓ Private use |
✓ Disclose source ✓ Include notice ✓ Same license (file) |
x Liability x Warranty x Trademark |
| Apache 2.0 | ✓ Commercial use ✓ Distribution ✓ Modification ✓ Patent rights ✓ Private use |
✓ Include notice ✓ Mandatory changelog |
x Liability x Warranty x Trademark |
| MIT | ✓ Commercial use ✓ Distribution ✓ Modification ✓ Private use |
✓ Include notice | x Liability x Warranty |
Interestingly, the MIT license is one of the rare licenses that does not grant users patent rights. This means that software or libraries licensed as MIT may end up in a larger work under a patent — even though the original code wasn't patented to begin with. So far, all the other licensing schemes we've seen prevent that either by granting explicit patent rights and/or by including patent retaliation clauses in the license.
Granting explicit patent rights means that users and/or contributors of software containing patented technologies licensed under those terms are also granted rights to those patents with the license. Fundamentally, a patent doesn't provide more rights to its custodian than to license owners. Yet, being a form of intellectual property typically granted by an institution (e.g. a government), owning a patent may provide additional weight in a legal recourse when trying to enforce a license. And this is why patents are still sometime seen in Open Source landscapes.
It remains, however, a polarising topic. For instance, the GNU GPLv3 license goes as far as stating the following:
Every program is threatened constantly by software patents. States should not allow patents to restrict the development and use of software on general-purpose computers. However, in those that do, we wish to avoid the special danger that patents applied to a free program could make it effectively proprietary.
GNU GENERAL PUBLIC LICENSE, Version 3, 29 June 2007
Others, like MPL-2.0 or Apache-2.0, include patent retaliation clauses as an extra protective measure. Such clauses usually entail that if anyone — contributors or users — attempts to sue another user or contributor for patent infringement, they lose rights primarily granted by the license (e.g., to use or modify the software). Retaliation clauses discourage attempts to bypass the license terms via patent litigation. This can be effective when software contains patents held by different contributors.
Indeed, suing any contributor for patent infringement also immediately revokes one's ability to use patent rights previously granted for the same licensed work. Given how software is built today with many layers of dependencies, this can mean a lot! For example, imagine you are building a software service that uses 50 other software libraries licensed under Apache-2.0. And you decide to patent some of the new techniques you develop in your software, which you also distribute under Apache-2.0. Then, you notice someone has forked your project and made a few changes. For example, they improved your patented techniques for their own needs. Should you decide to sue them for patent infringement, you'd automatically lose all patent rights from the 50 libraries you depend on, which, in many cases, represent a substantial part of your larger work.
So far, we've primarily described what Open Source is and where it came from. Yet, why did this movement appear to begin with? We have touched on that, and the story of the FOSS movement might have also given some additional clues. We could summarise the motivations behind Open Source in a simple statement: building software is a complicated endeavour, so it's better done together. In many aspects, Open Source is an attempt at building better, more robust software faster. It emphasises sharing and collaboration, which thus encourages improvements and iterations of existing software from various sources. In contrast, proprietary software is often driven only by one company's priorities. Sometimes, it is even simpler for companies to provide extra support to users than to fix or rework an existing piece of software. Let's see this clearly and delve into the value and benefits of having an open-source strategy.
Open Source is, first and foremost, a development methodology. It is an approach which favours frequent releases and short iteration cycles. It is inherently agile, as users drive requirements and roadmap unpredictably. There aren't two identical open-source projects. Some projects may be dormant until a particular life event makes it suddenly popular, drawing attention from many developers simultaneously. Some others may sustain a constant activity and steady development. Yet, what's common to all is how maintainers must constantly adapt to their users. Some will report bugs or request assistance, some will ask for specific features, and others may propose or implement new features.
As a result, through well-defined processes, constant efforts from open-source maintainers and sometimes a bit of magic, projects evolve organically in a very agile manner into something useful to many. For this to happen, open-source projects must have clear contribution guidelines and accessible instructions for building, developing and testing the project. Because a project is only instrumental if it has users, successful open-source projects are also those that make it easy for their users. This means providing good interface references, tutorials, user manuals, installation instructions, and other documentation that is relevant to the project. Some projects even document their design decisions through approaches such as Architectural Decision Records to make the work of future maintainers -- which may as well be their old self -- simpler.
Adopting an open-source strategy is a means to enforce those practices for many organisations. Who would not want a project -- even internal -- to be well-documented and accessible? By following an open-source approach, organisations reduce the risk of a project becoming hard to maintain. They enforce an excellent separation between software components and ensure that software quality converges towards excellence. With many users and contributors chiming in, software only becomes more robust. Indeed, people may run into unidentified software defects or inaccurate documentation pieces. So, the more eyes, the merrier.
Another critical factor leading to the choice of an open-source strategy is the need for transparency. This may sound obvious, but it is a strong enough argument for many organisations. The reasons behind it may be plurals: regulation, trust, security, etc. Making a project Open Source is a way to share accountability with a broader audience. However, it is a double-edged sword, as people may find critical defects that might have escaped the maintainers' scrutiny. Yet, on the other hand, defects are found — and hopefully fixed. Open Sourcing a project often comes as a token of goodwill proving that a specific product or algorithm conforms to its pitch. By giving access to the source code, interested parties can dissect and deeply audit a project, thus unveiling or nuancing any invalid claim.
As an immediate consequence, Open Source has proven crucial for fostering innovation in the software industry. As many scientists campaign for public access to science literature, open-source advocates underline the importance of sharing source material to drive software development further. Even for industry leaders, open-sourcing software stimulates competition and encourages better approaches, which may directly benefit their primary business activities. Some aspects we've seen earlier about open-source licensing relate directly to this.
The software industry is full of examples of large companies working on and improving open-source materials. Linux is notably the most successful open-source project to date. It has led to countless derivative works known as Linux distributions with some prevalent ones such as Ubuntu. Linux's development has not only led to a robust operating system toolkit. Still, it is also responsible for countless useful tools commonly used by all software engineers. A well-known success story in the development of Linux includes Git, a distributed version control system that has become the de-facto version control system for many open-source and proprietary software alike. Besides, prominent actors in the software industry are also known for their open-source contributions. Google, for example, released Android in 2008 as the first major open-source mobile operating system derived from Linux. Today, Android powers more than 70% of the mobile phones across the entire world. Continuing with Microsoft, which has given birth to TypeScript, a widely used programming language on the Web, as well as Visual Studio Code: the most used integrated development environment (IDE) by a large margin with countless plugins, integrations and packages developed by a large community of enthusiasts. As a last example, Those are very concrete examples of innovations rooted in Open Source.
The choice of Open Source for such large innovative projects makes even more sense when seen through the lens of ownership and governance. Large projects such as protocols, operating systems, or programming languages have a much better chance of success when built in the open with an open governance model. Hence, the idea of inclusive meritocracy often drives Open Source projects. Said differently, contributions are welcomed from anywhere, and the best ideas are adopted.
How do you determine the best ideas? Simply put, they are the ones that work and end up gathering support from a community. This view is fundamentally Darwinian: the survival of the fittest.
At times, projects are expected to split around some core design decisions. This is typically called a fork. Contributors and users will then follow one path or the other. Over time, this can lead to various outcomes:
- a merge of the fork back into the original project once an agreement is found;
- an abandonment of the original project, superseded by the fork;
- an abandon of the fork which didn't get any traction;
- two separate ecosystems solving similar problems with different trade-offs.
Mind you, a fork is often perceived as an ultimate course of action. There are usually many steps between. People often engage in public forums about design decisions or new ideas to gather sentiment toward specific evolutions. Projects do not necessarily seek consensus, and the majority isn't always the winning side. Between an idea supported by the majority but not implemented and a less popular idea immediately available, there's a strong chance for the latter to be adopted.
All in all, every project is different, and its community must pick a governance model that works for them. Those who fully embrace Open Source will document their decision-making process, and those who agree with its premises will then form a community. Those who disagree can fork the project and continue on a different path. Only time can tell what ensues.
This resilience to time is another core reason encouraging organisations to adopt an open-source strategy. It is hard to predict the business requirements of tomorrow. Harder even is to predict what people will want and do in the future. Building projects in the open through collective intelligence increases their chances of lasting longer. Open-source projects that thrive are first-and-foremost projects that have a large user base. Arguably, the best way to know what software to build is to ask those who use it. When a project is built collectively, everything about it, including its processes, roadmap and user documentation, is meant to allow anyone to understand and pick up the project where it's at.
As a side benefit, when maintainers are no longer motivated or become unavailable, it remains possible to find new maintainers relatively -- provided the project follows an open-source approach. This is much harder to achieve on internal projects that require specific training and often rely on unspoken and unwritten knowledge.
In addition, even abandoned open-source projects remain helpful for posterity. Like relics of the past, they are full of teaching. They can be studied by future code archaeologists who might try to understand how projects got where they are. A failed attempt at building a novel database solution today may inspire tomorrow's database engine. When projects are kept private, knowledge and effort disappear into oblivion. Many organisations choose to open source projects as they recall them when they no longer present a competitive advantage. While this doesn't bear the benefits we underlined in the previous sections, it is still a valuable contribution to the grand scheme of building software.
Finally, marketing itself can be a driving factor of an open-source strategy. In the same way that a furnished portfolio increases your chance of getting a job, open-source projects can showcase organisations from a technical standpoint. Hence, Open Source also exists as a means to attract talent. Significant open-source contributions stand out. They demonstrate an organisation's ability to work collaboratively and transparently and can also convey ideas of software quality and working standards better than any discourse.
Some companies have become known through some of their open-source projects, fast-tracking them as software industry leaders and pioneers. This is the case, for example, of Netflix, which is widely known for its "Chaos Monkey", a resiliency tool meant to harden large infrastructure by randomly turning off live components of a production environment. This exposes organisations and their engineering departments to failures more frequently than usual, ensuring that they can promptly recover from failures -- should they be induced or from natural causes. Besides being a fascinating piece of engineering, this story makes for a great marketing pitch. It has indeed piqued the curiosity of many software engineers around the world.
Many people hear about Open Source and think: "This sounds great, I would like to contribute!". Yet, the task may rapidly feel overwhelming. Large open-source projects can span over millions of lines of code, thousands of modules and hundreds of active contributors. How does one make sense of that? And what does it even mean to 'contribute' after all? What if you're not a software engineer? Can you still contribute to a project? In the upcoming sections, we'll build an intuition for these questions and review some types of possible contributions.
The most apparent type of contribution which comes to mind is code. It is, of course, unsurprising given that consumers of Open Source software are usually software developers themselves. Often enough, a solution may only partially fit someone's need and may need one or two extra features they are keen on developing. It's also frequent for people to identify defects and issue a fix to upstream maintainers. Underneath it all, it's a win-win situation. Someone made a chunk of work available for free, saving someone else time and money. Contributing back to making the solution better is a nice gesture. Moreover, it removes the burden of having to maintain a fork. Indeed, as the original software evolves, users may be keen to keep up with its various updates. So, any change made to that software should be included in the original version so that new changes can be made without the risk of conflicting with the change.
Incidentally, code contributions aren't necessarily what maintainers are looking for at first, especially in the early phases of a project. It is rather complicated to reconcile code written by many developers. This is generally possible only when software has matured sufficiently and after architectural patterns and habits have emerged. New software is usually more fragile, and maintainers tend to be careful about including additions that may not account for the bigger picture. So, while it may sound the most obvious, it is best to always look for what maintainers are looking for first. We will come back to this shortly.
Nevertheless, code contributions can also happen without explicitly writing code. Code reviews, for example, are essential to reducing defects and improving overall code quality. Sparing an eye to helping peer review the work of others can be genuinely beneficial to a project and is often an excellent way to get started with code changes. Watching how others do it, their habits, conventions, etc., before doing any substantial work is tremendously beneficial.
Equally important yet often dismissed are contributions in the form of ideas. Open-source projects will typically discuss designs, issues and project evolutions in public. This is an opportunity for users and contributors to share feedback. Building software without users is complicated. So, as a project maintainer, direct feedback from users is immensely valuable, especially when the room is made for it. Platforms such as GitHub provide discussion threads, polls, Q&A and so forth to facilitate conversations. Many projects also set up more synchronous communication channels such as Discord or Telegram. It may sometimes not look like it, but hanging around on a Discord server and participating in discussions is a form of contribution.
When conversations lead to actionable items for a project, they become documentation. Yet, often, it is a very rough form of documentation. Part of the tasks revolving around software development consists of capturing those conversations as intelligible documents. Projects thus generally divide documentation along four dimensions:
- Tutorials: meant to teach basics and provide a learning experience;
- How-to guides: provide concrete steps to solve a particular problem;
- Explanations: general theoretical knowledge to help deepen comprehension;
- References: practical information to come back to for detail.
Writing good documentation is hard. Even harder is to keep documentation up-to-date as context evolves and parts move. While many software components can be automatically checked through tools and compiler rules, documentation often depends on human interventions. Users are typically the first ones exposed to documentation and, thereby, the ones stumbling upon quirks and mistakes. Fixing mistakes as they're found is an easy way to contribute to a project and something maintainers are almost always looking for. Feedback on documentation is also generally welcomed. Users are the primary audience for software documentation; it is written for them. It is thus only normal that they help tailor it to their comprehension.
Do you know what's better than good documentation? Beautiful, good documentation! Design work, in general, is well appreciated in Open Source and will be our 4th key contribution area. Besides, when software has a user interface, icons, typography, backgrounds, and layouts become integral to its development. Yet, graphical design is a significantly different job than software development. And it is rare to find individuals with both skills. So help is often appreciated.
Some open-source projects even entirely focus on design. For example, FontAwesome and Feather offer a bank of well-crafted icons ready for any project to supercharge its user interface with beautiful icons instantly. Google's Material Design is another successful example of an entire open-source design system. Over the years, it has spearheaded countless conversations and studies on user experience and how to build proper user interfaces.
Projects like Google's Material that become truly popular may even become a brand. Think, for example, about React, a prevalent frontend framework for building user interfaces. It has become so popular that it's not rare to see job ads looking for "React Developers". WordPress is another major industry brand that needs no introduction nowadays. In situations like these, design can be all over the place. An attractive website with illustrative diagrams or helpful animations makes for a valuable experience. A logo with a strong identity inspires confidence and attracts users and businesses. Beyond just "looking cool", it's also a sign that a project exists independently -- or, at the very least, that it aspires to it.
This naturally leads us to the next contribution sector: marketing. In many aspects, open-source projects are products. They have customers, stakeholders, roadmaps, identity and many traits that make them akin to products. Even though they are a special breed of products whose entrails can be dissected, they, like products, seek adoption. Oftentimes, projects start from simple ideas. They make someone's life easier. They are made public in case others would benefit from a similar solution. Yet, as they become popular, they demand more work and effort to maintain and build businesses around them, which is common.
As a consequence, the need to attract new users grows as well. In this context, marketing can take various forms, from 'spreading the word' to organising live events focused around a particular project. Articles, newsletters and testimonies can generate incredible momentum for projects — especially success stories. Projects often struggle to get their first critical users as many organisations still see open-source as a lower quality sandbox than so-called "enterprise software". Hence, it's common to see organisations standing in the back, waiting for someone else to take the first leap of faith and use open-source software in production before it's even famous. Adoption is much easier after a few success stories.
This is an important aspect that is easily undermined. Many brilliant open-source projects die off because no one gets to see them. Luck is an implied factor in a project's success. Still, efficient marketing can help provoke luck once in a while. Maintainers are often too busy building software and improving their tools. Yet, it's good to remind oneself that the very purpose of software is to be used.
So far, we've seen various contribution areas for various skill sets. Yet, what about situations where you are interested in contributing to a project but do not have the skillset or the time it demands to make valuable contributions? Or what if there's no need for your particular skill set because the project is at a phase where it doesn't need that particular skill set? Financial support can also be a practical contribution depending on the project's aspirations. It is standard to see sponsoring programs near open-source projects. Various platforms exist, for that matter, such as Github Sponsors or Open Collective.
Some projects are also part of larger groups, such as foundations, which usually have membership programs and various ways of accepting financial contributions. Sometimes, it's easier to let projects decide for themselves where they need to pull resources. Often, project maintainers only work part-time or are just plain benevolent, for they cannot sustain themselves financially through a project. Platforms like Buy Me A Coffee also encourage people to support projects through small donations. This is a nice gesture that can have a positive impact on maintainers. A coffee and a small appreciation note can change someone's day radically, particularly when they prevent countless work hours and trouble ahead of you.
Finally, we will conclude this tour of contributions with an aspect that is also too often overlooked: technical support. Paradoxically, this is where Open Source shines almost at its best. This is what makes Open Source such an attractive model. Open Source is, before all, a community-oriented approach. Building a community is challenging, yet a strong community that looks to each other is precious. In the closed-source world, users usually expect technical support from the organisation selling the software. And there's only so much that a single entity can do.
In Open Source, the entire world is the technical support desk. All the other users and contributors who have gone through the same issues can help. In general, support tickets are even publicly available or happen on public forums such as Discord or StackExchange. Since everything there's to know about a project is publicly available, any enthusiast may build a deep understanding of a project. Coupled with past experiences, this means users are very capable of helping each other without any help from core project maintainers. When communities reach levels where they can support each other, nothing can stop them. During the early phases of a project, it is often up to the maintainers to help and guide people through. Yet, as the project and community matures, their role steadily shifts towards providing the community with better resources to help themselves.
By now, we should have a better understanding of what a contribution is, as well as reasons that would lead individuals or companies to go Open Source. Let's explore ways of contributing. By that, we mean to talk about the mindset and expectations that contributors should ideally approach Open Source development with.
In some cases, Open Source has become a criteria companies use when evaluating candidates. So, more and more individuals entertain the idea that they have to contribute to open-source projects somehow. In addition, initiatives like HacktoberFest have also popularised and encouraged people to contribute to open-source projects in exchange for rewards. Yet they have been, at the same time, heavily criticised for their negative impact on projects. In fact, many contributors lose sight of the original goals of Open Source to the point where maintainers would deal more with spam than actual impactful contributions.
Hence, we cannot stress enough that Open Source has one fundamental reason for its existence: sharing solutions to practical problems. In hindsight, it implies that utilising software is at the core of any open-source endeavour. And it is particularly true of contributions. There's a seemingly natural progression from user to contributor and, possibly, to maintainer. But it always starts with using the thing you might contribute to. It requires understanding the in-and-out of an application to propose changes and improvements or give feedback — the more thorough the usage, the more complex the contribution.
So, you've been using this tool for a while, and are you now willing to contribute? The first thing to look for is the project's license terms. Most open-source projects will use one of the common licenses we presented earlier, sometimes with a twist. However, it is also common for young projects to overlook this aspect entirely and not provide clear license terms. However, it is paramount to take notice of the license before contributing as it defines the framework within which contributions are allowed and the liabilities of the authors.
In most jurisdictions, the absence of a license automatically puts a project under an 'all right reserved' copyright for its author as a protective measure. Yet, in the absence of a license, we strongly encourage contributors to contact maintainers or authors to clarify this point with them.
Once the license question is sorted, one should consider whether contribution guidelines are provided. Typically, software projects that welcome contributions explicitly mention them in a README or CONTRIBUTING file.
Contribution guidelines set the expectations from the project maintainers and provide additional details about how to engage with the project beyond the licensing terms. They cover elements such as communication channels, workflows, quality standards, style guides, or tools to enforce any of those. When projects provide explicit contribution guidelines, contributors must familiarise themselves with them beforehand. Project maintainers routinely provide templates for proposing ideas or reporting bugs to guide contributors into writing better reports.
Over time, disagreements beyond technical debates may also arise within communities. People being made of different fibres often means that expectations, behaviours, and culture can be vastly different from one individual to another. So, in the same way that workflows and technical guidelines are provided, adopting a code of conduct is also commonly seen in open-source communities.
If you're about to propose changes to someone else's work, it's probably a good idea to talk to them first. Besides, it requires a lot of discipline (and extra overhead) to keep outsiders deeply informed about every workstream and design decision on an ongoing project. To avoid any misunderstanding, double-work or simply frustration, it is usually recommended to get in touch with maintainers through means they recommend prior to proposing changes.
A change request may come at the wrong time because maintainers are already working on a significant new feature. Or the change was already proposed and rejected a few times because it has trade-offs that maintainers aren't willing to accept. While source code is easily made available, context is much more challenging. And the best defence against misunderstanding is communication. If there's no way to contact maintainers directly, opening an issue/discussion ahead on a code repository platform (e.g. GitHub) is usually welcome. And remember to follow contributing guidelines if there are any.
To conclude this section, it's important to remind readers that not every discussion or bug report is equal. This observation becomes increasingly accurate as projects gain popularity and are used by a large number of other projects. All useful software has bugs, and when bugs can lead to exploits, they fall under the category of vulnerabilities and should be handled with care. Openly reporting a vulnerability before any fixes might have dramatic consequences on a project and businesses depending on it.
In such a situation, it is recommended to follow a procedure of responsible disclosure. The exact procedure varies from one project to another, depending on the severity of the vulnerability. Typically, a group of trusted individuals are appointed security officers and alerted in case of vulnerability. Fixes are then worked on silently and issued in a future release. Once patched and deployed, publishing a post-mortem explaining the vulnerability and how it was found is quite common. The Apache Software Foundation provides, for example, a rather exhaustive list of steps to responsibly handle any Apache project's security vulnerabilities.
Strong open-source projects are those that manage to build an efficient governance. Of course, since every project is different and comprises various people, finding an ideal governance model is a challenging task. By governance, we refer here to the ultimate decision-making strategy in a project. Indeed, Open Source in itself doesn't necessarily specify rules by which contributions are accepted and handled. Who decides what features get in or when the software gets released?
Like companies, projects often start small and grow organically into a structure that fits them. Yet, we can broadly categorise commonly seen models as one of five categories: founder-leader, do-ocracy, self-appointed steering committee, elected committee, and single-vendor. Let's quickly see what each entails.
The founder-leader model is the most common type of governance model -- per number of projects -- found in Open Source. This is a simple model and the most intuitive approach for many projects where those who originated the project decide on its evolutions. Founders impulse the vision and administer the project. This works well for projects with few contributors, where founders have enough capacity to deal with all requests and decisions. This model shows its limits as soon as projects grow beyond what the founders can manage. Yet it's common to see successful and large projects, like the Python programming language, still rely on this approach as an ultimate authority. Projects are split into smaller areas where decisions are made relatively independently as they grow. The vision and final decisions on strategic decisions often remain under the founders' responsibility.
In Open Source, accessibility to raw materials and contributions from the community are an integral part of a project's life. So naturally, many projects embrace do-ocracy as a governance model. In other words, decisions are made by those who do the work. In this approach, projects settle on a few metrics they recognise as suitable for measuring contributions and naturally listening to those who have contributed the most. Earning a seat at the governance table means actively contributing to the source material. This approach is particularly well suited for projects demanding expertise in a specific domain. Those who prove capable of doing so are also trusted for their judgement and ability to assess problems correctly. Interestingly, this model is often perceived as an absence of governance since there's no one designated authority but rather a context made of many interactions between people who recognise authority in the makers. Nevertheless, this remains a governance model of its own.
Some projects prefer to keep a separation between those who make and those who decide. Hence, technical councils, steering committees or boards of directors constitute a third type of governance model. Broadly speaking, self-appointed councils refer to projects where members designate a group as the acting authority on the project. A self-appointed committee typically forms out of a general agreement when needed and decides its succession rules. Generally, communities resort to self-appointed councils to resolve conflictual situations between their members. Councils act as a mediation body representing the interests of the project. The risk here is for a committee to turn into an ivory tower where governance seems out of reach from new contributors unless chosen by that greater authority. Hence, self-appointed councils work best when they have a specific mission to tackle for a fixed period.
As a natural evolution, self-appointed councils often turn into elected steering committees. In this approach, projects decide on a voting procedure and rules for election ratification. Elected members typically come from the project community and want to represent another part of the community. They may also be members who want to get involved in the project's decisions and who are appreciated for their leadership. Projects that follow this type of governance tend to be quite mature and have a well-documented process.
Finally, projects exist where a single organisation or vendor handles the governance. This is essentially the case for business entities who decide to open access to some of their projects. Open source projects under this type of governance are mainly maintained by a single vendor who wholly owns the roadmap and the contributions allowed within the project. This model works well for projects that adopt an open-source strategy for reasons other than community governance, such as being more transparent or attracting talent. Yet, they only generally seek external contributions when immediately aligned with their strategy.
Open Source isn't a business model but rather a development model. Many projects fail to succeed in Open Source because they overlook entirely their business concerns. Yet, the lack of a business model usually leads to their end rather than choosing to go Open Source per se. There's no such thing as a free lunch. And while open-source projects might not generate revenue directly, they ought to be part of a larger commercial strategy. A good business model is essential to the sustainability and liveness of long-lasting Open Source projects. But where does the money come from?
A commonly seen business strategy around Open Source regards services sold on top of the project. These services typically include support, training or consulting. This type of business model feels natural because it's among the easiest to monetise. The expertise obviously lies within those building and providing the software, and it's already natural to provide support to users. Building a business model around it thus feels like a logical next step; many even see it as part of the job. What's being sold in the end isn't the software but the expertise that comes from building and using it for a long time.
This model, however, presents a few intrinsic contradictions. In a way, making the software more straightforward, accessible, better documented, etc., goes somewhat against the business. No one needs support or training if it's too easy to use. One could argue that it's always possible to offer support and expertise and that making some parts easier allows spending more time on trickier aspects.
Similarly, since selling software is no longer an option, selling convenience can become a lucrative activity. Said differently, while the raw software may be freely available for use, modification, etc., it may still require to be deployed on some infrastructure, monitored or made more accessible through some graphical user interface. Hence, offering the software as part of a higher-level service or as a cloud-based solution can be monetised. This is about selling convenience and removing the hassle of running your software. This is particularly suited for end-product software like e-commerce solutions or databases.
With this type of business model, companies no longer compete on base capabilities but on the best interface that makes them available while collectively maintaining a robust foundation. Think about software libraries such as ffmpeg, which is the backbone of arguably any video processing application (online or desktop) on the planet. It is a library that is so featureful that no one gets any clear market advantage from introducing a new feature alone. Instead, different applications use a subset of the available features to solve specific use cases differently. At the same time, everyone shares a common interest in keeping the library up-to-date, efficient and bug-free.
Open Source is also very much a spectrum. Some contexts encourage people to go entirely open source, while sometimes, only part of a software project is open. This is often referred to as an "open core" strategy where the foremost part of an engine may be made open and available to the public, while extensions or plugins would remain closed-source and commercialised separately. It is a canonical scheme for data-heavy software such as databases or analytics tools. For example, a database engine may be fully Open Source while offering integrations through various accounting services on the side as paid software.
Having the core part Open Source opens up the development to other use cases not covered by the commercial part, possibly indirectly benefiting the paid extensions. Consequently, it might encourage using the base solution to increase its market share and make plugins more visible and attractive. So it's a win-win situation. The underlying risk with this type of business model is knowing where to draw the line. A counter-intuitive incentive encourages a software provider to implement new features as closed-source paid plugins instead of contributing them to the upstream core. However, drawing the line at the right place ultimately makes the project successful.
Another typical funding mechanism for open-source projects is sponsorship or crowdfunding. This is particularly true of small projects that do not have the capacity to build businesses in addition to their open-source development efforts.
Sponsorship then usually takes one of two forms: external sponsorship from actors who are directly interested in seeing the project continue -- likely because their own business directly depends upon it or simply as a genuine token of recognition. It can also take the form of patronage, where a company recruits maintainers and provides them with resources to keep doing their work. Both forms usually include perks and contracts agreed between maintainers and sponsors to clarify expectations from both ends. For example, maintainers may give a higher priority to fixing bugs impacting a paying sponsor.
Finally, we consider royalties the last prototypical form of open source business model. Software used to produce other artefacts (other software or media) is a good candidate for this category. Video game engines such as Unreal or Unity use such a model where the game engine is provided for free and source code made available upon the condition that games produced with the engine pay some royalties back once they meet a certain level of success.
This model works exceptionally well for these scenarios as it encourages the maintainers of the original software to build better software to produce better results and maximise their revenues. However, this type of business model can be hard to enforce and typically requires more paperwork and legal recourses than the other. Code source tends to be provided only upon proper written agreement between users and maintainers.
Open Source is an approach geared towards sharing and transparency, so it is naturally an excellent vehicle for metrics and analytics. In that regard, measuring success and progress on an open-source project can differ from how it's typically done for traditional commercial software. One measures usage, adoption, and appreciation over time instead of counting the number of licenses or copies sold.
It always starts with users. Without users, there's simply no Open Source. Thus, it is arguably the most vital metric to measure. But how exactly? It depends on the nature of the project. For libraries published on a package registry, it's generally possible to consult direct or transitive usage analytics and dependent packages. There's no one number to aim for, but comparing with similar, comparable libraries to see how healthy a project might be is always interesting. For full-blown software, one can look at downloads and installations when possible. Again, such elements are usually readily available when the software is shipped through a package manager.
In addition, the retention rate is similar to usage and possibly equally important. It can be harder to measure, but it provides an excellent metric for measuring user satisfaction to some extent — especially in the presence of alternatives. Developers might stick to a particular piece of software for a variety of reasons, of course, such as performance or ease of use, so it's generally good to look for additional metrics that can be quantified.
A second sign of healthiness for projects comes with the number and nature of contributions. Frequent contributions are a testimony of software accessibility and maintainability. Conversely, software that is harder to penetrate or requires a much larger context to ingest upfront tends to receive little to no contributions. If receiving contributions is a goal, then it is essential to spend time organising the project in a way that facilitates contributions. That is, the documentation shall cover more than installation instructions and usage but also cover workflows typically done by project maintainers, such as building from sources, testing, releasing, etc.
As we've seen in the previous sections, contributions may take very different forms besides code changes. A well-defined bug report is immensely valuable, and getting projects in a state where users are guided into writing good tickets ought to be an aspiring goal of any open-source project. People in society tend to mimic the behaviour they observe. For example, if everyone had taken their shoes off when entering the room, the next person would likely have taken them off, too. Similarly, when a code repository is well organised, with carefully crafted bug reports following a clear template and process, the next person to open a ticket will feel more compelled to follow the process.
So, it's important to remember that project maintainers are the first contributors to a project and that it isn't reasonable to expect other contributors to do something that maintainers do poorly. As a maintainer, setting the right example is capital.
Finally, since Open Source is about sharing and collective ownership, it is particularly relevant to examine community engagement. Do people spread the word about the project? Are blog authors writing articles about it? Does the name often appear on social media in an appropriate context?
Engaging with a community is primordial, and monitoring its impact is key to identifying gaps in the documentation, awkward interfaces, or areas for improvement in general.
So far, we have mainly discussed the benefits of Open Source and the variety of advantages it may bring to a business seeking to build the best software. If we were to stop here, the scenery would appear a bit magical, wouldn't it? Of course, Open Source isn't a silver bullet either, and one must be aware of its drawbacks or limitations before venturing into those lands.
Many great soul gets lost along the path as they get chosen by Open Source. In many situations, success arises from an unpredictable mixture of good ideas, timing and luck. Oftentimes, one gets propelled as a maintainer of a popular open-source project in little to no time, and suddenly, users start having expectations. Hearing about burnout and depression is, regrettably, a common practice in Open Source. One primary reason is the emotional investment and passion that maintainers consistently put in their work. On the other end, users with a strong sense of entitlement can get quite demanding, creating dissonance for maintainers working for free and without any joint agreement.
Therefore, it is crucial to put clear barriers in place from the start for their sanity. For example, disabling push or email notifications helps make the workload pull-driven to avoid being crushed by external pressure. It's also good to remind oneself that working for free while being treated harshly is also called 'slavery'. The role of a maintainer isn't to deal with each and every temper. This is why, as a protective measure, it is sometimes necessary to ignore individuals and not engage with bullies. Easier said than done, of course. The world wide web is a vast place.
Because of their nature, open-source projects routinely begin as hobby projects. As a famous saying goes: developers produce the best software precisely when they're working on something other than what they were supposed to be doing in the first place. Behind this riddle lies a hard truth about Open Source. In and of itself, Open Source isn't a business model. It is, at best, a development model. Consequently, it must be coupled with a business model to be sustainable in the long run. Maintaining a sizeable open-source project is a full-time job, and unless something is actively done to prevent it, it doesn't bring any money at the end of the day.
As we pointed out earlier, maintainers are usually driven by passion and regularly overlook this critical component. Transitioning from a hobby into a full-time job isn't always easy or natural for maintainers. Many aren't particularly interested either and would often bail out of maintenance early on. Truth is, the fun aspect of solving a problem is to solve it. Then, improving and perfecting the solution is, fundamentally, work. For those who decide to continue, either for their own project or for someone else's that they love, the question of funding must be taken seriously. As we highlighted in the previous sections, there are many ways to fund Open Source, but nothing happens alone.
There's one prominent fear amongst businesses embracing open-source: competition. In fact, Open Source may sound like giving your only business advantage to the competition, leaving you at the mercy of any bigger player with more resources. In The Economics of Programming Languages, Evan Czaplicki jokingly refers to this as "being Jeff'd" in reference to Amazon Web Services and Jeff Bezos and their ability to take any software from the Open Source and offer it as a new cloud service. The risk is real, specifically if your entire business model relies solely on providing cloud services. History shows that this regularly happens for a project that gets large enough.
However, different offers and competition can be good drivers for innovation, and they are no different from typical business problems in the proprietary world. Plus, there's an indirect incentive for everyone to contribute back to the original project and avoid long-running forks that are harder to maintain. Thus, collaboration still happens backstage, and large players with more resources may even contribute significantly.
Finally, the most common problem faced by open-source projects is adoption. We are now reaching the end of this course, and it should now be clear that getting users is the root of many elements. There are no contributors without users. And to be frank, there's nothing like seeing people solving their problems with software that you shared. Yet, reality sometimes decides differently, and the solution you thought would solve everyone's problem only really solves your problem. Or perhaps people haven't found it yet. Platforms like GitHub definitely help with visibility and discoverability, but one should also uphold the importance of communication and marketing when it comes to Open Source.
Things also take time, years even. It is hard to predict what will be the ultimate trigger that promotes a project from a niche hobby solution into a world-class open-source ecosystem. Be patient, and pay attention. In the meantime, keep building.
- https://opensource.guide/
- https://opensource.com/resources/what-open-source
- https://opensource.com/open-source-way
- https://www.gnu.org/philosophy/free-sw.html
- https://choosealicense.com/licenses/
- https://choosealicense.com/appendix/
- https://www.linuxfoundation.org/resources/open-source-guides/
- https://adr.github.io/
- https://documentation.divio.com/
- https://paulgraham.com/opensource.html