1. 36
  1.  

  2. 13

    The article doesn’t seem to appreciate that fork is exit.

    1. 11

      Fork is exiting but bringing a copy with you.

      Imagine leaving the store and walking into an identical store but now the walls are blue.

      1. 6

        Soon you find that the blue coat of paint cost a pretty penny; and that you now have to pay your new shop’s rent, as well as hiring staff to run & maintain it.

        For a hobbyist it’s less of a risk; but for a business maintaining a fork of a significant piece of software can become an albatross around your neck, or can result in a significant business opportunity—or anything in between. Thus I’d caution against rash forking: evaluate carefully whether it’s worth it in your case.

        1. 11

          Then you always have an option to exit, same as before, with only moderate-to-low sunk cost.

      2. 5

        Not necessarily.

        It’s also a way of formulating voice into a coherent and proven valid response.

        A “Pull Request” is a “voice” asking the original developers to “to hear” a fully fleshed out and proven valid suggestion.

        They may choose to take it as is where is, or tweak, or ask it to be reformulated, or reject.

        Once rejected, the fork may choose to exit, or partially exit.

        1. 3

          Is Debian exiting Linux since they have their own fork of it? I don’t think so.

          1. 2

            There are many levels of exit so we can argue endlessly about what is and isn’t exit and all be right within a particular frame. A person leaves the living room of a house and goes to their own room where they have control within parameters. This is the same as the Exit, Voice, and Loyalty case of someone leaving an organization. Outside, they have control within parameters - usually set by the government they are under the jurisdiction of. For Debian, the control factor is their users and their choice to follow Linux. They can change their mind about all of those things without asking permission of the repo they forked from.

            So, yes, it’s all a matter of how you frame exit. FWIW, it’s a big question in political science whether exit exists at all, but I think that it is obvious that it does as long as one isn’t binary about it. It exists in degrees and at particular levels.

        2. 2

          I wish there were some examples. How often does this forking happen? If it’s something rare that happens only when the stars align (person knows to program, has expertise in the source code but chooses to outsource the service in the first place, doesn’t have a viable competitor to exit to for less effort than forking), does it matter?

          1. 3

            I think private forking happens all the time. I keep patches for several programs on my system. What happens rarely is organizational forking, ie. an attempt to set up a competing development team. A historic example would be the EGCS GCC fork, which was so successful that it just became the official GCC project.

            A maintainer has to mess up pretty bad for that to happen, and most projects that attempt this just starve for lack of people caring about their version.

            That said, Wikipedia has a list (of course): https://en.wikipedia.org/wiki/List_of_software_forks

            1. 2

              I’m very curious to hear about such private forks! It seems to me that the current state of open source doesn’t make them easy or convenient. Creating a fork isn’t just a one-time expenditure of effort, it’s an ongoing effort thereafter of keeping up with upstream. I’ve personally tried to do this multiple times and invariably given up. So I’m curious to hear how long you’re able to continue maintaining a fork for, and any tricks you have to minimize the overheads involved.

              (I actually don’t care about organizational forking. Organizations are certainly more likely to be able to afford the ongoing opex of maintaining a fork. But the original Exit vs Voice concerns people in a civic organization, and that tends to be my focus as well.)

              1. 4

                It seems to me that the current state of open source doesn’t make them easy or convenient

                It depends on what you’re doing with a private fork. If your changes are relatively minor it’s just merging from mainline periodically which modern VCSs are pretty good at.

                As an example, I participate in an OSS project that includes a third party library to provide a rich text editor in-browser. IME is very important to us, but not as high-priority for the library. We maintain a “private” fork (it’s publicly readable, but I no one else really cares that it exists) that differs mostly in the form of disabling a couple of features that interfere with IME. Occasionally we’ll merge code from a branch bound for release that hasn’t made it to mainline yet because we need it sooner. Maintenance involves pulling from upstream and re-evaluating our patches every couple of months. The most inconvenient part of it is having to self-host the built packages, which all things considered really isn’t bad.

                I mean it’s a kludge, we’d obviously rather not have to spend the small amount of effort required to maintain a “private fork”, but I’d much rather have the option than not.

                1. 1

                  Oh certainly, it’s nice to have the option. Taking it back to OP, I just wonder if your example is worth considering on par with “exit and voice.” It seems rather the equivalent of putting dinner on a plate after purchasing it.

                2. 3

                  IME, Gentoo makes this sort of thing pretty easy, at least for basic changes. You don’t have to maintain the repo, you can just stick your patches in /etc and have Gentoo autoapply them on rebuild. So you only need to do maintenance if they stop working, and in that case you will already have the repo checked out in the state Gentoo is trying to build from. So you just copy the build folder, reapply your patch, take a diff and stick it in /etc again.

            2. 2

              The user can invest less effort into persuading the developer, because they can ultimately just make the change themselves.

              This article has the same flaw a lot of articles about open source do: it assumes that the user can code. If someone doesn’t know how to program, it doesn’t matter that they can technically make the change themself; fork is closed off entirely.

              1. 14

                The article actually says

                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.

                (my emphasis)

                1. 2

                  Not entirely. A sufficiently dedicated & deep-pocketed entity can pay someone else to make their desired changes.