There is a misunderstanding that needs to be cleared up straight away: open source does not mean "free". It means you have permission to read, modify and redistribute the software. The price is a separate question, and sometimes the answer is exactly the same.
The right question is another one: who decides what happens when something goes wrong? With proprietary software the answer comes from the vendor. With free software the answer comes from you, because you can read it.
The four freedoms
The definition is not mine, it is Richard Stallman's, and it has been written down since 1986. Software is free if it guarantees you four things:
- Freedom 0: to run the program for any purpose.
- Freedom 1: to study how it works and modify it to suit your needs.
- Freedom 2: to redistribute copies.
Freedom 3: to distribute your modifications, so that others can benefit from them.
The numbering is not decorative: freedom 0 refers to running the program, and the following ones depend on it in the order Stallman defined them. That is why copyleft is tied to freedom 3 and not to any other.
The fourth one is what changes everything. It is not "free forever": it is that if someone improves the code, the improvement comes back to everyone. It is the only thing that makes collaboration at scale possible, which we talked about in Why IT security: collaboration brings greater security and efficiency.
The mechanism that makes the fourth freedom effective is copyleft, and it needs to be explained properly because it is the part that is most often misunderstood. Copyleft does not forbid you to sell: it forbids you to sell without giving back. You can take a piece of free software, market it, make a lot of money out of it, provided that whoever buys it also receives your modifications. It is the opposite of an "all rights reserved" licence.
How it started: 1983, a printer and an absurd project
The official history has a precise date and time: 27 September 1983, twelve fifteen in the morning. Richard Stallman, who at the time was working at the MIT AI Lab, posts an announcement on Usenet to build a free operating system called GNU, an acronym for GNU's Not Unix. He also announces that he is leaving MIT, because they had offered him a job in a laboratory that used proprietary software and he did not want to be paid to help make it mandatory.
The triggering reason is smaller and more concrete than the theory. Stallman wanted a printer in the laboratory, shared with other users. Every print job ended up in a queue, the work stalled, and when he asked the technicians why it happened the answer was that the management program was proprietary and they could not modify it. He could not even see the code. From there came the sentence that sums it all up: you cannot fix what you cannot read.
That same year the laboratory's operating system had also broken down, ITS, and with it the programming ecosystem that gave it substance. The GNU project was born from the loss of two things at once: a system to work with and the freedom to modify it.
In 1985 Stallman publishes the GNU Manifesto, which is a programmatic document, not a technical one, and founds the Free Software Foundation to give the project a legal structure. In 1986 the Free Software Definition appears, the one I quoted above.
1998: the split, and why it matters
In the meantime the world had changed. Free software had become profitable, and the open source community — Unix, Apache, Perl, Python — was growing for reasons very different from Stallman's.
On 3 February 1998, at a meeting in Palo Alto, the label "open source" was coined. Two weeks later the Open Source Initiative was born, founded by Eric Raymond and Bruce Perens. The OSI derives its Open Source Definition from the Debian Free Software Guidelines, which Perens had written the year before.
The point is not lexical. It is that "free" and "open source" do not say the same thing, and the author himself writes so explicitly. Stallman considers "open source" a marketing term, designed to sell the ideal of the four freedoms more effectively. For him freedom is an ethical question, not a competitive advantage.
It is worth knowing this, because the difference is the same one that runs between "software you can modify" and "software that is free of charge". They are two real things, but they do not coincide: there are programs that are free and closed, and programs that are free and cost money.
Why it is worth it: five technical reasons
1. The code is the definitive documentation. When a server will not start and the manual is not enough, in an open project you search. Someone has already run into your error, and often has left a comment. With closed software you can only wait for support and hope that someone understands.
2. No vendor lock-in. Lock-in is not a price, it is a dependency. If the only way to do backups is a vendor tool, if the only way to update is their procedure, if the only way to diagnose is to open a ticket: you are not using the software, you are renting it. With open code migration is work, not a betrayal.
3. Software ages badly in the abstract. A project from twenty years ago on which nobody earns money is no longer maintained, and with it every security patch. Whoever earns money maintains it: and if they stop, they do not do it on a whim but because it suits them to stop. This is a real problem and it should be said, along with everything else.
4. Flaws are counted in public. When a project is discussed by thousands of people, a vulnerability discussed in a public issue gets fixed quickly. It is not that open code is immune to bugs: it is that you cannot hide them.
5. It costs less, but that is not the reason. The saving on licences is real and has so far often been the main item in the account. But the item that carries the most weight is the last in the list: you do the maintenance yourself, with your own skills, and between two people who call about the same bug in the middle of the night the economics change completely.
The other side of the coin, stated clearly
Open source is not always the best choice, and those who support it should say so.
Support costs. Nobody guarantees you an intervention within an hour. With a paid product you pay for that, and you find that out first.
Interfaces change. A major release can move things that worked. With a proprietary product you pay for stability.
It requires expertise. Administering Linux and its services requires skills that Windows and .NET provide for a fee. The time saved on the licence you spend on training. If you do not have the people to do it, the balance tips negative.
It is not really free. Someone has to maintain the project. The model works when there is a company that does business out of it: Red Hat, Canonical, SUSE, GitLab. They are backers, not philanthropists.
The rule we use
The reasoning we follow at CYBER ONIONS is simple, and it is not "free is better". It is this:
If you can read the code of something you depend on, that thing is not yours. If you cannot, it is a favour they are doing you — and favours come with conditions.
From here comes the choice of PHP, Linux, MySQL, SQLite and command line tools. Not out of ideology, but because a closed infrastructure in ten years is a problem even if today it works very well. An open one is a set of tools we know, that we can still use even if they have changed, and that we can change ourselves.
The initial cost is a few extra hours of configuration. The saving is not having to start from scratch — and, if things go wrong, being able to look inside.