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". We could also call this "contribute" or "change", because this sense of "forking" doesn't have to be acrimonious or even public, and it doesn't imply a split in the developer community. 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.
This isn't like "voice"; the user doesn't have to persuade a specific group to make the change. And this isn't like "exit"; the user doesn't have to pay large upfront switching costs, and they don't lose access to all the resources that were already invested into the software.
For example, distributions and corporations frequently apply local patches to Linux to tweak some features to work better for their specific use case, while still participating in the broader Linux community. Consultancies like Igalia will make specialized changes to open source software for a fee, and open source bounties allow non-programmers to group together to pay such fees. More rarely, a fork splits the developer community such that the two resulting projects don't exchange code after the fork; this is always high-profile when it happens.
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.
Users (which might be other software) which are "portable" for a certain dependency can easily exit that dependency. That is, they can easily switch to different implementations of that dependency. Typically, the key to portability is using "portable features" (ones which are widely available in other implementations) and avoiding "non-portable features" (ones which are not available in other implementations).
For example, imagine there's a piece of software "FooSoft" and a proprietary library "libprop", and that FooSoft depends on non-portable features of libprop. If libprop changes (or refuses to change) in bad ways, FooSoft is reliant on voice to prevent (or cause) that change, because exit is hard.
If FooSoft instead sticks to only portable features of libprop, then if libprop changes in a bad way, FooSoft can exit easily. libprop can just be switched out for some other implementation. So, to preserve the ability to exit, FooSoft would prefer to only use portable features of libprop.
But imagine that there's an open source library "libopen". If FooSoft depends on non-portable features of libopen, then it will be hard for FooSoft to exit libopen. But this inability to exit libopen is less important, because FooSoft still has the option to fork if they want certain changes; this fork might only involve a few private patches to tweak some small behavior.
In general, it's less important for users to only use portable features of open source software. That's because the ability to fork open source software makes it less important to preserve the ability to exit that software.
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.
New features will continue to be added to the main version; to incorporate these, a fork needs to regularly rebase on the latest main version. Rebasing becomes harder the more the fork diverges from the main version. Thus a fork will want to keep its divergence from the main version to a minimum, and will use voice and exit, among other tools, to achieve that.
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.