It is not as simple as what those bozos hold.
If only it were that simple. You don’t like a product, that product is FOSS, so you just fork it to make the modifications you want, and you’re a happy camper, right? RIGHT? This scenario is often a pipe dream, not always, mind you, but often. Those bozos who bleat “just fork it,” irrespective of context, ignore the friction that is created with every fork. Actually, they probably do not know much about software development.
Sustainably forking a code base is a scenario that is most likely obtainable if the code base is small and simple. Sometimes I’ve forked entire projects that way. However, these entire projects were small. It is past a certain size and a certain complexity that things get quite complicated. I’d never dream, for instance, of forking some software made to design jet engines. I do know something about jet engines, but not nearly enough to make a fork worthwhile. Even if someone wanted to pay me for this task, I’d have to pass.
As the code gets more and more complex, various sources of friction manifest themselves more and more intensely. Here’s a super easy example. I’ve forked Mastodon, initially, to have more than 500 characters on my site. There is currently no other way to do it than to fork the code and edit a few files. It is running, now, on my site. Done, right? Wrong. Because my code is not in the official code base, now, every time a new release is made, I have to pull the new code and patch it anew, making sure that my changes still hold. This is one source of friction.
My patch is very simple, so I don’t expect a lot of trouble with it. However, the more complex the patch, the more friction it causes. I did get some friction when I moved from v4.1.6 to v4.2.0-beta1. It was a minimal amount of friction, but I had to rebuild one patch because the file name had changed.
Then there is the issue of interaction with the people who are developing the software. Some people are very welcoming of newcomers. Some are much less welcoming. Maybe you have this great patch that you’d like to submit, but if you encounter a brick wall when you submit it, your attempt at submittal was mostly in vain. Oh, and lest you think that all FOSS projects accept code patches easily, let me tell you that this is not at all the case. Some projects are good. Some are utter shit. This is yet more friction. In the good projects, this friction will be minimal, but still exist. In the bad projects, the friction will be such as to block any submission.
How receptive people are to changes, and the way they welcome new developers, can make or break a deal. I’d like to say that everybody wants all changes, and is very welcoming, but that would be a lie. I know from past experience that some individual developers, or even entire teams, are hostile to any contribution from newcomers, or they take these contributions as insults. I recently pointed out to a competitor of Mastodon that I could not follow a specific address. The answer was
Complain to them. It is not our problem.
This was the entire response. They know I’m new here, but they don’t tell me what I’m supposed to complain about exactly. This is a fuck you answer. Understood. I fucked right off back to Mastodon.
My advice: unless you completely understand what forking will mean in terms of friction, shut your mouth. You’re not helping anyone with your uninformed opinion.
Leave a Reply