Exit and voice in 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".

Open source provides a third option: fork

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

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 in the small town.

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.

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 the ability to fork. 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.