Last updated on November 21, 2018
Open source software, also known as free and open source software (FOSS), free, libre, and open source software (FLOSS), and free software, has become more and more popular these days. When starting a new open source software project, we developers tend to think mostly on the technical side of this project, e.g., what programming languages and frameworks to use, how to design the architecture of the software, what platforms to target at, etc. We not only think, we actually think about these really carefully: We look around for advice, struggle in our mind, and, sometimes, even after years, we still argue that we should rewrite the software in a different programming language. On the other hand, we often take the non-technical side too light without much thinking: We use a specific source code hosting service simply because everyone else uses it, we use a specific license simply because this is the only license that we are able to read through once and (vaguely) understand, etc. These decisions, however, will heavily affect the style, the advancement，or even the survival of our open source software projects.
This post aims at draw developers’ attention to non-technical aspects of open source software projects. We will have a brief overview of some non-technical aspects that can be important in open source software projects (while more aspects and details can be further discussed in the future).
Financial Aspects
Many people believe that open source and money are insulated from each other—How could one make money if the source code is public? In fact, money is the soul a cornerstone of the majority of long-standing and active open source software projects, and also the direct drive of many of them. Can you imagine that someone consistently spends days and nights working on a project for 10 years without getting paid for it? Perhaps some multi-millionaires living on an inherited trust can, but not most of us. Eventually, most successful open source projects seek out some financial solutions: Running a business behind it, finding sponsorships, etc.
Contrary to the popular misbelief of “commercial vs. open source”, the majority of successful open source projects have a business cause, either directly or indirectly. Businesses like developing open source software for various reasons, such as third-party contribution and community support (lower development cost), as long as it fits into their business model. For example, the Android open source project is led and directly used by Google to implant their Internet products into mobile phones, HHVM is led and directly used by Facebook for its own websites, and MongoDB is led by MongoDB Inc., which sells MongoDB-related consulting and training services, commercial licenses, etc.
There are other open source software projects for non-profit purposes, but they still figured out their own way to get financial support. For example, Firefox is maintained by Mozilla, a non-profit organization, generates revenue from search engine traffic and sponsored new tab tiles; Linux kernel is maintained by the Linux foundation, which is sponsored by a number of corporations; and, similarly, Eclipse is maintained by the Eclipse foundation, which is in turn sponsored by a number of corporations.
Anyway, the take-home message is: If you want your open source software project to be sustainable, think seriously about its financial aspects.
Development Environment Aspects
The development environment here includes not only the tools that directly help write code such as IDEs/editors and debuggers, but also the development infrastructure on which developers and users communicate and contribute, such as the source code hosting website, the issue tracker, and the discussion platform. In this post, we focus on the latter one, as it involves a lot of non-technical elements besides their technical elements.
While most of us developers do care about the development infrastructure, we often focus too much on its usability (from a technical perspective), such as how are the APIs it provides, how many integrated service it has, etc. For this aspect, I think Dr. Megan Squire’s recent research paper Considering the Use of Walled Gardens for FLOSS Project Communication makes an interesting point. According to Squire, the core value of open source software, or alternatively FLOSS, has two components: freedom and openness. Freedom refers to the freedom to use, understand, modify, and redistribute the software. Openness refers to the openness of its development process, including transparency (e.g., transparent communication and decision making), and inclusivity (e.g., diversity and easiness of community participation). The choice of development infrastructure mainly affects the openness of the project and should balance between transparency and inclusivity. However, recently, the open source community seems to start losing this balance:
… communicating in “walled gardens”, or non-open and corporate-controlled systems such as Slack or Stack Overflow, and not keeping archives of this communication puts the FLOSS goal of transparency into conflict with the goals of ease-of-use, inclusivity, and diversity of participation.
After investigating 18 open source software projects, Squire concluded that
Unfortunately, our data shows that only a handful of projects have made any attempt toward transparency by opening such a gate (into the walled garden). This resistance to creating transparent archives of communication also persists in communities such as ASF (Apache Software Foundation) that explicitly encourage archives and transparency in project communication.
While Squire only talked about communication platforms, similar concerns apply on other kinds of development infrastructures as well: Does your choice of internationalization platform allow exporting existing contributions? Does your project hosting website, such as GitHub and BitBucket, allow you to export contributed contents easily (or even legally)? In short, we should always ask ourselves the question: Does the development infrastructure (on which developers and users communicate and contribute) conflict with your core value of open source? The answer varies depending on your value of open source. For me, I would ask questions such as
- Is the development infrastructure itself open source?
- Will this development infrastructure monopolize the project, e.g., no exporting?
- Does this development infrastructure require contributors and users to agree with unreasonable agreements, e.g., abusing user information?
- …
Legal Aspects
(I Am Not a Lawyer and this is NOT legal advice.)
Open source software is a piece of intellectual property and has complicated legal properties. For an open source project, perhaps the most relevant legal issue is with regarding to licenses. This includes the licenses of the project itself and its dependencies (including non-software dependencies such as artworks).
The License of the Project
Software licenses are legal instruments that grant and restrict users’ right to use, modify, and redistribute the software. Roughly speaking, open source software licenses are special kinds of software licenses made for open source software. They typically grant users the full right to use, study, or modify the software (including its source code) and allow some forms of redistribution.
Normally, you would need to use an explicit license: No explicit license doesn’t mean other people can use your software to do whatever they like; rather, the default copyright rule applies and other people may not even have the legal right to use it. Also, normally, you would not want to draft a license by yourself, as it’s easy to make mistakes. Rather, you should choose from existing common licenses that have been well tested. Common open source software licenses include GNU General Public License (GPL), the Apache license, the MIT license, the BSD license, and so on.
The license of choice should match your goal of the open source software project and should be carefully considered. If we chose the wrong license initially and decide to change the license after a lot of contribution has taken place in the future, it can be a huge hazard. For example, VLC’s license change in 2011 requires getting signatures from 150 developers; a poll shows that MongoDB’s recent change of license in 2018 impacts about 50% of its users. Choosing wisely in the first place is an important step to reduce the chance of a license change in the future.
Open source software licenses commonly fall into one of the three following categories: permissive licenses, copyleft licenses, and weak copyleft licenses. While they all grant users the full right to use, study, or modify the software for their own use, their mainly differ in the permission of redistribution:
- A permissive license permits any form of redistribution including under a proprietary software license and not releasing the modified source code. Examples include the Apache license, the MIT license, the BSD license, and public domain.
- A copyleft license permits redistribution as long as the redistributed version is licensed under the same license (and is therefore also open source). Examples include the GPL family.
- A weak copyleft license is something in between. Examples include the Mozilla Public License and the Eclipse Public License.
In short, the choice depends on the extent to which you are willing to have part or the whole of your open source software included in a third-party proprietary software. Based on the answer to this question, I believe you’ll be able to make a rational decision.
There are certainly more details such as patent grant and tivoization to think about. I recommend you to read the briefs of the licenses (and even their full text) listed here for details.
The Licenses of Dependencies
The most important thing to consider with respect to the licenses of dependencies is their compatibility with the license of your open source software. Roughly speaking, License X is compatible with License Y if a software licensed under Y can include dependencies licensed under X. Compatibility also varies by the forms of dependency. For example, is the dependency used as a shared library or static library? Is the dependency also included as data (e.g., artworks) in your project?
For more details, you can check out the Wikipedia page on license compatibility.
Conclusion
This post aims to draw open source developers attention to non-technical aspects of open source software projects and gave an overview of three such aspects: the financial aspect, the development environment aspect, and the legal aspect. There are certainly other aspects to pay attention to, such as governance (e.g., democracy versus dictatorship) and marketing, that can be further discussed in the future. Anyway, the take-home message is: Non-technical aspects of an open source software project can be important and even determine its fate, and we open source developers should pay more attention to them.