Free and Open Source Software is an umbrella term to define a wide variety of software whose source code is available (open), and can be used, copied or modified with a minial set of restrictions (free). This software is often also “gratis”, but not necessarily. FOSS is part of mostly every major engineering component which powers our life. It is in Android phones as the linux kernel, in your banking apps, in the Operating Systems for every microcontroller in your car, everywhere in the web, where it powers engines, websites-generation toolkits, servers, and touches basially everything you can think of. Major Silicon Valley companies nowadays all publish vast amounts of free software. However, despite its ubiquity, many people still wonder where is it, who owns it, how can I use it, and benefit from it. In this blog post we will try to answer some of those questions, delving into the actors, sinergies, and logics of FOSS.
FOSS at its core: communities, humanity, people… and money?
So far we have talked about FOSS in general, but for the following discussion, we are going to critically differentiate between two kinds of FOSS projets:
- Those owned by a company that require external contributors to hand ownership of their changes to the company (yes, even if working for others!). Although FOSS now, these projects have no warranty of remaining like that into the future. So they are FOSS now, and in theory, but most of the discussion does not apply. A very clear recent example of this situation is Terraform.
- Those owned by a community, each of its individual contributors (which also, of course, includes companies). Some of those have one or several companies in charge of steering the project, but the contribution model warranties that they will remain FOSS.
Doing this differentiation, although subjective in nature, is common for companies that rely on FOSS, like Amazon. You can read more in detail on these differences and why they are important here. Out of these, we will focus only on the second kind.
Communities in an era of companies
Each FOSS project has its own life. But most of those which interest us, share a common base: they are driven by a community. That does not exclude a wide variety of governance models, from one or a few companies doing the core steering of the project, to specific foundations being in charge, a group of individuals democratically elected, or the more odd but still common model of a Benevolent Dictator For Life[ˆ1]. So, if they are so different in how they are managed, what makes them all communities? We can try use the second definition of community in the Oxford dictionary to help us define them as a group of people who share the same interest in a piece of software they together develop. The most importants part of this definition are people, and together. So why are those important?
Together we move forward
Let’s start with together. FOSS has one quite interesting property, it can always be modified and redistributed, by any party (a person or a company, be or not be part of the community) at any time (some licenses might apply certain retrictions on how that is possible, but that’s a topic for next section). So, if you don’t agree with the course of a certain FOSS project you can always take it, change it, and redistribute it at your liking! This process is commonly called forking. And it breaks together. If often means that you, and the original project split your efforts, leading to less feature development, more bugs, and greater costs. Therefore, there’s usually a common interest to remain together, as long as the cost of doing that: the bargaining, convincing others, having to sometimes re-implement solutions at other people’s liking, etc. do not become unnecessarily high. And that applies to you, but also to other parties! So you can get much more features, fixes, and in general development, just contributing to a part of it. And therefore, at a fraction of the cost! If you become a respected member of the community, you can also get to influence the course of the project, and therefore work with others for them to implement things you both need! This whole idea encourages collaboration between the different stakeholders, but also allows the flexibility to decide where you want to go, but taking the state of the project with you.
And many previous experiences show that this is an extraordinarily successful model. At Combine, our most applicable scenario is MATLAB vs. Python. Many years ago, any engineer within Controls or Data Science needed a MATLAB license for their work. MATLAB was the go-to software for any engineering or mathematics calculations, both at the industry and at universities. However, as Python became increasingly popular, the appeal of not paying for licenses grew. And that added to the benefit of letting data scientist develop their work more freely, changing the software if need be. Nowadays, no data scientist at Combine requires a MATLAB license, and we’re proud contributors to the accelerator Python-based FOSS project!
In people we trust
Now that we know the “together”, how does that relate to “people”? Well, many open-source communities are full of people that contribute on their free-time as volunteers or not-for-money. Or of people that despite being hired by a company, execute their work quite autonomously. Or of people that have been working on the same project for a long period of time, sponsored by different employers. And although their employers (if they exist) can often set priorities and define requirements, they cannot take over the project decision-making, (remember “together”?), since for they start, they do not have full control over it. This often leads to interesting sinnergies, were decision making and features depend more on trust from the community, than on who puts the most amount of money on the table. It would not be the first time that such pile of money is rejected based on contributors not trusting the source. Or the first time that a big feature is rejected, because it comes from somebody not known to the community, that did not follow established (written or unwritten) conventions.
So how do you do then, as a company, interact with FOSS? There are many options, but we’ll just provide some examples. At Combine, we have engineers with FOSS experience. We let them contribute to FOSS when they need to, and ask them to help us when we need to interact with FOSS communities. If they are part of them, they can better engage and avoid common mistakes. Of course, they also teach internally when needed. But if you do not see this approach fitting, you can use NASA’s one, which consists of a combination of collaborating with projects when needed, releasing FOSS when best fitting, and donating to projects they vitally depend on, for them to keep doing what they are doing.
Know your licenses, but can we make money?
One very common misconception about FOSS is that it is impossible to make money from it. In the end, it is mostly free Software, right? Who pays for something that is free?
As we mentioned at the beginning of the article. Free refers specifically about what one can do with the software, not about its price. It’s completely legal to sell FOSS. However, one has to admit, it’s not the most common situation, and in fact, most FOSS is provided free-of-charge. The reality is, that opposite to proprietary software, the right to use and change FOSS does not come from the vendor, author, or redistributor. It comes from the license, that every contributor agreed to, itself. Once somebody received a piece of free software, the vendor completely handed the rights of the software to the user or client. So then, again, how do we make money? Without trying to present an exhaustive and complete set of business models, let’s look into some examples:
- For providing updates. Nobody likes to use old and outdated software, that might break with future updates to the stack. There is therefore an economic incentive to update, and continue paying the redistributor.
- For long-term support, for an established service. Even though Python might be free, surely many companies pay for long-term support of Python versions considered end-of-life by the Python project.
- For support questions and help. Expert knowledge is precious, and many companies are willing to pay for it to supplement their needs. Whether the software provide is or is not FOSS does not really have an impact.
- For hosting or providing a service. Of course anybody can run a gitlab instance, but most people do not want to. Therefore gitlab offers to do it for their clients.
- As an integrated service with more components, where the FOSS is an enabler for the rest. This of course requires being careful and respecting the licenses, but is a very common practice.
Hopefully, by now it should be pretty clear, that there are plenty of ways of making money. But which are the benefits then? Mostly, reduced costs, increased development speed, and shared expertise. These days, virtually every product in Combine’s portfolio includes or is built with FOSS, which avoids us having to reinvent the wheel. However, to do that one needs to be aware of the details regarding the licenses of the FOSS projects one is using. The benefit compared to non-FOSS licenses is that there are just a handful of licenses, they are wellknown, never change, and have been studied for many years. They come without surprises, and quite often come in the form of a handful lines of text, that require no lawyer to interpret.
[ˆ1] That exactly the model of Python. See https://en.wikipedia.org/wiki/Benevolent_dictator_for_life for more details and examples.