What the fork is a 'fork'?

Forking code isn't a bad thing. It isn't a good thing. It's just a thing.

The past couple of days you've probably heard the word "fork" more times than you can count. Facebook forked this(even though it didn't), Amazon forks that, the Chrome team forked the whole web, and so on and so on. While everyone is talking about who's forking who, nobody is bothering to explain exactly what forking is, and why so many people have an issue with it.
Forking, or shattering, got a bit of a bad rep back 20 years or so ago, as it tended to split up developers into separatefactions who weren't sharing the code with each other. In the days of things like the Gnu-Emacs/XEmacs split, this was important because there weren't nearly as many people capable of working on these big, open-source projects, and having two branches or forks meant it takes longer to add features and address issues for both sides. In some cases this still happens, I'm sure, but for the most part there are plenty of developers who can fill the void left by those that have a separate vision and will fork off code to follow it. But some folks never forget, and the stigma attached to forking forkers gets passed down. Having said all this, we can't pretend bad forks don't happen. We just need to look past the act itself before we make our decisions.
I know a few of you out there know what all this means, and are just trying to ignore all the noise, but for many it's confusing. Let's try to fix that.

What is a software fork, and how does it affect Android?

Think of Android a a bunch of code. There are two portions -- the open-source parts, which is what AOSP is, and the proprietary parts that Google keeps to itself. If someone wants to take Google Android and make changes to it, they will download the code to use as a base, and form their own project with it. Samsung does that, HTC does that, and your favorite ROM developer might do it. Anytime someone takes existing code, and starts an independent(that's an important distinction) project based on it, they've created a fork. Many developers will check out code, edit portions of it, then send their changes back upstream in their entirety, which is not a fork.
Amazon raised quite a few eyebrows when it forked Android to build the OS for the Kindle Fire line. But on the open-source side of things, it was no different than what Motorola did with the Cliq, or HTC did with the Hero -- or what Samsung does now for the Galaxy series devices. This is how many big open-source projects work. Every vendor (except maybe Amazon) works with the same basics, likely reporting bugs and submitting fixes back upstream as they go along, to create their own take on the final product.

Facebook didn't fork Android. It used the Android intent system (a way apps can work with each other and share on Android) and built a big app that additionally includes a substitute home. Inside their sandbox, they can do whatever they want or need to do, and as long as they use Android's intents, they can communicate with the rest of the system. If you want to get technical, HTC may have forked Android to work better with Facebook Home in the HTC First, as it mentions some changes that were made for better compatibility. We'll know more about what they did when the phone trickles out.
In any case, forking codeisn't a always bad thing and doesn't deserve all the negativity you hear when someone mentions it. Industry analyst Stephen O'Grady sums it up nicely I think:

Its worth mentioning, however, that from a customer perspective, forks or variants are not universally bad. While the various Android versions may represent unfortunate design decisions on the part of the vendors responsible for them, applications are in the overwhelming majority of cases compatible from device to device, assuming version equivalency.

Having apps compatible from device to device is why Android was designed. Forking code doesn't make that not happen. But other things do.

The other side of forking Android

In China you can buy a phone from a carrier that runs Android, but has no Google services? Just like the Kindle Fire, it's built from Google's Android code (sometimes unmodified) but was not submitted and tested to be Google compatible and have things like Gmail or Google Play included. Those apps, and the assorted system files that they need to run, are not open-source, and you can't just include them without permission from Google.
Other than a "different" (I'm not going to say it's "worse", only different) user experience without these apps, they can look and feel just like an Android phone you buy from Verizon or AT&T. They can also look and feel very different, like Amazon has done. But none of this is because they forked off Google's Android code -- it was a conscious decision to not make a Google "certified" device. Google presents Android as an application platform and set of app frameworks. Not including Google's service applications doesn't make it any less of an app platform. Of course, we imagine Google would rather have all Android and Android-based devices use Google's services, but there is no hard-and-fast rule that says a vendor has to do it.
Making devices without Google's apps has nothing to do with forking Android. It may make devices less desirable, or one day the ultimate Android phone could be built without Google's apps, but it can happen without forking any code. We're all guilty of meshing the two things together, but we shouldn't do it.

Forking is just a thing

It's not good that OEMs fork out Android and work on their own project with the code. It's not bad that OEMs fork out Android and work on their own project with the code. It's just a thing they all do.
Nexus fanclub aside, you can't tell me Samsung or HTC has ruined Android by forking the code and building on it. They added features while keepingeverything compatible so that applications built for "Android" according to the developer guidelines will work just fine. And they consistently deliver devices that people want to buy. I think this is exactly what Google had in mind for Android. They knew that eventually someone would go a bit further and create something that's not fully "Android" compliant, but that's OK. Users of those devices are still on the Internet, and Google's mobile web apps are pretty decent.
Hopefully, now you know a little more about what people mean when they talk about forking Android.

Via: What the fork is a 'fork'?