Forking

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 separate factions 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?

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 fork

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 code isn'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:

It’s 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

Kindle Fire

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

Angry mob

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 keeping everything 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. 

 

Reader comments

What the fork is a 'fork'?

32 Comments

And we got to remember that the Android Kernel itself was forked from the Linux Kernel, and have evolved apart for years.

Jerry, you are the man! Your articles are ALWAYS good reads. When I see "written by Jerry", I don't care if its about cheese whiz and keyboards. I know its going to be entertaining. Keep up the great work!

Oooh... Did Jerry really write an article about cheese whiz and keyboards? I bet that would be epic ;)

BTW: I love the Fleetwood Mac video at the end, Jerry :)

I don't think this is really an accurate summary of what is and is not a fork. What groups like Amazon, HTC, Samsung, etc. do is not a fork. They are maintaining patches on top of an existing project (android), but they are still using that project as a base, and applying their changes on top of that base. When the base is updated, they update their version as well (not necessarily right away, but eventually). They don't worry about maintaining all the low-level AOSP stuff, they leave that to Android and just take care of their own changes. Similarly, Android is not a fork of Linux, is it a set of changes using Linux as a base, and periodically pulling in the latest Linux base.

A fork is different. A fork, in the sense it is discussed in, for example, the webkit case, the projects are now completely separate. Google is no longer putting their on changes on top of webkit, they are maintaining an entirely separate software project from top to bottom. Although the two projects start off with a similar underlying code, the code will diverge over time to become completely separate pieces of software. Some changes might be copied back and forth, but as the software diverges this will be increasingly difficult.

The reason such forks are often frowned upon is because in practice there are generally not that many people working on such projects, so dividing the effort between two or more projects will mean less gets done on either project. There is often only have a handful of people who are critical to a project's continued progress (this is called the "bus number", the number of people who have to get hit by a bus for the project to collapse). There are often lots of other contributors, but they contribute much less. So forking can seriously negatively impact a project's ability to move forward.

However, forking is not always a bad thing. For example if there are fundamental, irreconcilable differences in how factions within the project view the goals or the future of the project, then forking may be the only option. If there are legal or leadership issues that are holding the project back, then forking may be the only option.

But forking is never a small issue. It almost always causes deep rifts in the project's community and produces a setback as the fork has to worry about rebranding, reorganizing, setting up infrastructure, etc. It may be the only option, but it is not something to be done lightly.

Thanks for clearing that up. Also im pretty sure anyone in the open handset alliance arent allowed to fork Android, hence that isn't what HTC or Samsung do.

Much more accurate explanation of what is a fork, TheBlackCat. The problem is some people call fork to things that are really not. A fork in AOSP projects is finally bad for the user. Less things done. Forking also, and most of the times, causes confusion for the user. Which is better? The original or the fork?

Exactly. Jerry forgets the real reason why folks hate forked code. Diverging code breaks compatibility and interoperability.

Google hasn't forgotten that is why they put a halt to Tizin.

I'll have to respectfully disagree.

Without knowing exactly how, when, and where OEM partners get their codebase, both of us are just guessing.

It's my suggestion that Samsung (again, for example) receives this code, and starts to modify it to their liking. When a newer version comes out, they do not try to update the original, instead they create a new project base from it. The original "Google Android" code they received is not updated with Google's patches and commits. This is why it's so difficult for something like a patch to the AOSP browser to find it's way to devices, and instead users are left to wait for a system version update for core Android fixes. Samsung's ICS branch is independent and static once Google RTMs, minus the modification Samsung needs to do to make it more compatible with their vision.

If vendors were to just have patches that apply over the RTM version of Android, we wouldn't be constantly waiting for security patches and bug fixes that Google has implemented in the base.

Exactly, its not as simple as copy and pasting the new android base in, or else updates would be MUCH faster. They are clearly rebuilding things from quite a low level based on how long it takes them to get updates out. I would agree with Jerry that most OEMs fork

Interesting response, but just because you fork, doesn't mean you cannot contribute to the other road.

If during the fork Google finds and error in something with webkit are they just going to keep it to themselves? No i believe they would pass it back over either formally or informally.

Same with android and amazon. They may have different end goals but at heart they would contribute back and forth on the main road.

Fork - To branch or split off the main path while maintaining some of the previous path. Example: You come to a fork in the road while traveling. You can go right, or you can go left. Either one you choose you can still track your travel back to the beginning.

@ piizzadude: Yes, as I said, "Some changes might be copied back and forth, but as the software diverges this will be increasingly difficult."

And as I pointed out, Amazon is not a fork, it is a set of changes on top of the android code base. It is not a separate project, it is an additional layer and set of changes on top of an existed project, in the same way that android is not a fork of linux.

I just want a forkin' fone that works out of the box without forkin' bugs. Fork all this. I'm going back to a forkin' feature fone. Fork ya!

While I know what is meant by "fork" when it comes to computer related things, I have not heard the term in so long I kept thinking that people were just using it in place of another 4 letter word starting with F and ending in K

Only thing I would beg to differ is on the following:

"Nexus fanclub aside, you can't tell me Samsung or HTC has ruined Android by forking the code and building on it."

That statement might hold true for Samsung, but it most definitely does not for HTC. As it stands, they are in the fast track for bankruptcy in the near future.

Even if that was true and HTC was on its way to bankruptcy(which I highly doubt) How would that ruin Android?

I'm guessing the software they have integrated with Android is why you don't get buttery smooth on htc and samsung in jellybean, which still lags, like you do on nexus devices.

@blackcat I have to disagree to an extent. Amazon is a fork just because the goals are different than intended.

What is important for a fork is that they are split into two entirely separate projects with the entire software stack developed independently. If one project is based off the code from the other project than it is not a fork, it's just a patch set.

One of the whole points of software development is that well-designed software can be used for substantially different purposes than for what it was originally intended. That does not mean that the software was forked, merely that the software is flexible.

In the open-source world, this is generally referred to as "upstream", which is the core project, and "downstream", which are the other projects that base their work on the core project. In the case of android, the linux kernel is the upstream of android. Similarly, for both google's android and Amazon's android, AOSP is their upstream.

I did a search for fork defintions, please take a look at:

http://www.webopedia.com/TERM/F/fork.html

"To split source code into different development directions. Forking leads to the development of different versions of a program."

http://computer.yourdictionary.com/forked-version

"Program source code that differs from a main body of code. At some point in time, the code was taken and modified to produce a different product (the forked version)."

http://en.wikipedia.org/wiki/Fork_%28software_development%29

"In software engineering, a project fork happens when developers take a copy of source code from one software package and start independent development on it, creating a distinct piece of software. The term often implies not merely a development branch, but a split in the developer community, a form of schism."

Note that in each case, the critical factor in a fork is that the project is split into two entirely separate projects. If it is just patches on top of an existing project, even if those patches substantially change how the project works, it is not a fork, since it is still being based on the original project. In that case it is just an upstream and downstream.

Generally speaking, I dislike reading internet comments. Hopefully by now you've inferred that doesn't apply to you :) I have nothing of substance to add to this downstream of the original comment section

This is a GREAT article. I admit, I was thinking forking was a AC slang way of saying the F-bomb. But this article is so descriptive and definitely should be in one of those "Android Central 101" type articles or whatever they call it here. Something for easy reference.