The basic concept is as follows: members of an organization, whether a business, a nation or any other form of human grouping, have essentially two possible responses when they perceive that the organization is demonstrating a decrease in quality or benefit to the member: they can exit (withdraw from the relationship); or, they can voice (attempt to repair or improve the relationship through communication of the complaint, grievance or proposal for change). For example, the citizens of a country may respond to increasing political repression in two ways: emigrate or protest. Similarly, employees can choose to quit their unpleasant job, or express their concerns in an effort to improve the situation. Disgruntled customers can choose to shop elsewhere, or they ask for the manager.Exit and voice are also two possible strategies for a software user, who might be one person, or an organization of multiple people.
If the user would like the software to change, or would like it to stop changing, they can employ either "exit" or "voice".
Let's call this ability "fork". That's a bit of a misnomer, because this sense of "forking" doesn't have to be acrimonious or even public. A user might make some private change to the software which they know wouldn't be accepted into the main version, while still making other changes as part of the main community.
The ability to fork has implications for "exit" and "voice".
Since exit is essentially one's only option if voice fails, people will do things to make exit easier - like taking a job in a big city where there are many other jobs.
In software, one of the key influences on the ability to "exit" is portability. Portable software can be used on different platforms or with different dependencies and portable data formats can be read by different programs.
For example, if a piece of software "FooSoft" depends on non-portable features of a proprietary library "libprop", the piece of software can't easily stop using the proprietary library. FooSoft and its users are reliant on "voice" to make sure that libprop changes only in good ways.
If FooSoft instead only depends on such portable, widely available features of libprop, then if libprop changes in a bad way, libprop can just be switched out for some other implementation of those features.
Making it easy to "exit" in this way is the primary motivation to write portable software.
For open source software, it's less important for users to preserve the ability to exit from the software, because they can fork it instead.
If, as in the example before, FooSoft depends on a non-portable feature of an open source library "libopen", and libopen changes in a bad way, FooSoft can fork libopen and continue using it.
So it's less important for software to only use portable features of open source dependencies.
One might compare this to a (possibly apocryhal) process for achieving change inside large corporations: Leave the company, start a startup implementing the change and demonstrating that it works, and then have the company buy that startup. The ability to fork makes this process much faster.
This is only an approximation of the truth, of course. When the original developer has resources that aren't copied in a fork, forking becomes harder.
Some resources that might not be duplicated in a fork:
This can be mitigated by good documentation, but of course can never be truly solved.
This can be especially troublesome when the software depends on specialty hardware. A community-friendly project will try to make it easy to create a development environment so that the software can be built. Other projects, sometimes intentionally, will make it harder to build modified versions of the software.
Even if a service is open source, the resources used to host that service are not duplicated in a fork. Most obviously, unlike normal application software which runs on the user's computer, a service depends on computers controlled by the service provider. To use the service, the user must set up copies of such machines, rather than simply run the software locally.
Another factor is that changes on top of a fork usually must be regularly rebased on top of the upstream project. The more significant your changes, the harder this becomes. Thus the more you diverge from mainstream usage and the fewer people who agree with your approach, the higher the cost of maintaining your fork, and the more important it becomes for you to persuade others with voice, or to exit to a more friendly project.