OPEN SOURCE The Double-Pointed Nature of Forks
IT STARTED OUT INNOCENTLY ENOUGH. There I was, setting up my VPS with Docker, getting my blog and other services running. Eventually, it came time for me to install OwnCloud (an open-source cloud project that offers a replacement for things like Dropbox a
I looked at the most popular container that wasn’t the official one provided by OwnCloud. With over 100,000 pulls, the l3iggs/owncloud container seemed to be the way to go. But there was one major hiccup: A June 4 update mentioned that some OwnCloud developers had left to start their own company— Nextcloud—to work on a fork of OwnCloud.
For those new to open source, a fork is a big deal. It’s common for developers to pull code from a project and work on a specific feature of bugfix in their own branch of the project. That code is usually merged back into the main branch, which is the code in the end product that users typically run. A fork, on the other hand, is like a branch, except that it abandons the main project entirely, and uses the branched code as a base for the new project. The fork’s code is maintained separately from the project it is forked from, and usually has different leadership and mission objectives. Project forks can eventually totally revamp the code base, if needed.
If you’ve been using free and open-source software for a while, there have been a few famous forks to note. LibreOffice and MariaDB forked from OpenOffice and MySQL respectively, after Oracle acquired those two. More recently, the Chromium team started Blink, a fork of the WebKit rendering engine (that powers Chrome and Safari). Plex is a proprietary fork of the popular HTPC software XBMC (now known as Kodi). Even the popular WordPress is a fork from b2/CafeLog.
Forking a project can create a lot of strife, as developers are often forced to choose sides by deciding which project they will contribute code to. This is the case with the OwnCloud fork, which saw one of OwnCloud’s co-founders split off to form Nextcloud, bringing a large number of developers with him.
Users are faced with problems whenever there is a fork, too. Users of the old software have to choose whether to continue with the current product, or switch to the new one. Compatibility becomes an issue over time, so this choice can become time-sensitive, as the fork and original projects release new versions. New users or users looking to install software on clean systems are faced with a similar problem. When presented with two similar packages, they have to make a choice about which project will be better maintained in the future. While this can be predicted by looking at the number of contributors, pulls, and commits for a project on GitHub, few users look at those numbers when wanting to type a simple apt-get install. Also, forked projects often have to play catch-up to provide mobile apps, official binary packages, and official Docker containers.
So, is it better to go with a fork? Maybe. Major forked projects that I’ve listed, such as WordPress, LibreOffice, and MariaDB, are better maintained than the projects they originated from. But forking is never a smooth path, and the fork may experience bumps in the road as it tries to find its footing. For projects like Nextcloud, that you’ll be entrusting your data to, it’s a good idea to keep backups of your data, just in case something breaks.
As for my VPS, I’ll install Nextcloud (via the greyltc/nextcloud Docker container), fingers crossed.
Forking can create strife, as developers are forced to choose sides by deciding which project they will contribute code to