Exit and voice in free/open source software

Quoting Wikipedia on the classic social science text, "Exit, Voice, and Loyalty":
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".

For open source software, there's a third option. Both the user and the original software developer have the same power to change the software. So if the original developer refuses to make some change, the user can find some other person with programming skill, and ask (or pay) them to make the change instead.

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".

Exit is less important for open source

In different situations - not just in software - "exit" can be easier or harder. For example, someone working in a small town will have fewer job opportunities than someone working in a big city, so exiting a bad job is harder.

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.

Voice is less important for open source

In the use of "voice" in software, there are two participants, the user and the developer. The behavior of both sides is changed by voice. On both sides, some of the effort that would otherwise be spent on voice is instead shifted to implementation work through forking.

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.

When forking becomes harder, exit and voice become more important

The "fork" ability relies on the user being able to get a complete copy of the resources used by the original software developer. Anything the original software developer can do, the user can now do.

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:

All this weakens the ability to fork and forces software users to depend more on exit and voice.

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.