How to destroy FOSS from within - Part 3

This is the third installment of the article.
In case you missed it, these are part one and part two.




In the previous post, I stated that the direction in an FOSS project is set by two groups of people:
a) People who work on the project, and
b) People who are allowed to work on the project.

We have examined (a) in part two, so now let's examine (b).

Who are the people allowed to work on the project? Aren't anyone allowed? The answer is a solid, resounding, "NO".

Most FOSS projects, if they are contributed by more than one person, tend to use some sort of source code management (SCM). In a typical SCM system, there are two classes of users: users with commit rights, who can modify the code in the SCM (committers), and read-only users, who can read and check-out code from the SCM but cannot change anything.

In most FOSS projects, the number of committers are much smaller than the read-only users (potentially anyone in the world with enough skill is a read-only user if the SCM system is opened to the world e.g. if you put the code in a public SCM repository e.g. github and others).

The committers don't necessarily write code themselves. Some of them do; some of them just acts are a "gatekeeper"; they receive contributions from others; vet and review the changes; and "commits" them (=update the code to the SCM) when they think that the contribution has met certain standards.

Why does it matter? Because eventually these committers are the ones that decide the direction of the project by virtue of deciding what kind of changes are accepted.

For example, I may be the smartest person in the world, I may be the most prolific programmer or artists in the world; if the committers of the project I want to contribute don't accept my changes (for whatever reason); then for all practical purposes I may as well don't exist.




Hang on you say, FOSS doesn't work this way. I can always always download the source (or clone the repo) and work it on my own! No approval from anybody is required!

Yes, you can always do that, but that's you doing the work privately. That's not what I mean. As far as the project is concerned, as far as the people who use that project is concerned; if your patches aren't committed back to the project mainline, then you're not making any changes to the project.

But hey hey, wait a minute here you say. That's not the FOSS I know. The FOSS I know works like this: If they don't let me commit this large gobs of code that I've written, what's stopping me to just publish my private work and make it public for all to see and use? In fact, some FOSS licenses even require me to do just that!

Oh, I see. You're just about to cast the most powerful mantra of all: "just.fork.it", is it?




I regret to inform you that you have been misinformed. While the mantra is indeed powerful, it unfortunately does not always work.

Allow me to explain.

Fork usually happens when people disagree with the committers on the direction they take.

Disagreement happens all the time, it's only when they are not reconcilable that fork happens.

But the important question is: what does the forking accomplish in the end?

Personally, I consider a fork to be successful if it meets one of two criteria:

a) the fork flourishes and develops into a separate project, offering alternatives to the original project.

b) the fork flourishes and the original project dies, proving that the people behind the original project has lost their sights and bet in the wrong direction.

In either case, for these to happen, we must have enough skilled people to back the fork. The larger the project, the more complex the project, the more skilled people must revolt and stand behind the fork. It's a game of numbers; if you don't have the numbers you lose. Even if you're super smart, you only have 24 hours a day so chances are you can never single-handedly fork a large-scale project.

In other words, "just.fork.it" mantra does not always work in real world; in fact, it mostly doesn't.

Let's examine a few popular works and let's see how well they do.

1. LibreOffice (fork of OpenOffice). This is a successful fork, because most of the original developers of OpenOffice switch sides to LibreOffice. The original project is dying.

2. eglibc (fork of glibc). Same story as above. Eventually, the original "glibc" folds, and the eglibc fork is officially accepted as the new "glibc" by those who owns "glibc" name.

3. DragonflyBSD (fork of FreeBSD). Both the fork and the original survives; and they grow separately to offer different solutions for the same problem.

4. Devuan (fork of Debian). The fork has existed for about two years now, the judge is still out whether it will be successful.

5. libav (fork of ffmpeg). The fork fails; only Debian supported it and it is now dying.

6. cdrkit (fork of cdrtools). The fork fails; the fork stagnates while the original continues.

7. OEM Linux kernel (fork of Linux kernel). There are a ton of these forks, each ARM CPU maker and ARM boardmaker effectively has one of them. They are mostly failed; the fork didn't advance beyond the original patching to support the OEM. That's why so may Android devices are stuck at 3.x kernels. Only one or two are successful, and those who are, are merging back their changes to the mainline - and eventually will vanish once the integration is done.

8. KDE Trinity (fork of KDE). It's not a real fork per se, but more of a continued maintenance of KDE 3.x. It fails, the project is dying.

9. MATE desktop (fork of GNOME). Same as Trinity, MATE is not a real fork per se, but a continued maintenance of GNOME 2.x. I'm not sure of the future of this fork.

10. Eudev (fork of systemd-udev). The fork survives, but I'd like to note that the fork is mostly about separating "udev" from "systemd" and is not about going to separate direction and implementing new features etc. Its long-term survivability is questionable too because only 2 people maintain it. Plus, it is only used by a few distributions (Gentoo is the primary user, but there are others too - e.g. Fatdog).

11. GraphicsMagick (fork of ImageMagick). The fork survives as an independent project but I would say it fails to achieve its purpose: it doesn't have much impact - most people only knows about ImageMagick and prefers to use it instead.

I think that's enough examples to illustrate that in most cases, your fork will only **probably** survive if you have the numbers. If you don't, then the fork will either die off, or will have no practical impact as people continue to use the original project.

In conclusion: The mantra of "just.fork.it" is not as potent as you thought it would be.

As such, the direction of the a project is mostly set by committers. Different projects have different policies on how committers are chosen; but in many projects the committers are elected based on:
a) request by the project (financial) sponsor, and/or
b) elected based on meritocracy (=read: do-ocracy) - how much contribution he/she has done before.

But remember what I said about do-ocracy?

Posted on 14 Nov 2017, 23:57 - Categories: Linux General
Edit - Delete


No comments posted yet.

Add Comment

Title
Author
 
Content
Show Smilies
Security Code 6228145
Mascot of Fatdog64
Password (to protect your identity)