Phabricator Administrator's Handbook/Compare Phabricator and ...

People often compares Phorge (ex Phabricator) to other technologies like Bitbucket, GitLab, GitHub, Launchpad, Mantis bug tracker, ecc.

Having said that no solution is just "better" than another one, this page will help in having a background in how some various similar technologies are designed and how they differ.

Differences between Phorge and other solutions

	Phorge	GitLab Community Edition	GitLab.com	GitHub.com	Bitbucket.org	Launchpad	Launchpad.net	RiouxSVN.com
Libre Software	✅ yes	✅ yes	🟠 yes	❌ no	❌ no	✅ yes	✅ yes	❌ no
Possibility of Self-hosting	✅ yes	✅ yes	❌ no	❌ no	❌ no	✅ yes	✅ yes	❌ no
Custom domain	✅ yes	✅ yes	❌ no	❌ no	?	✅ yes	❌ no	❌ no
Bug tracker	✅ yes	✅ yes	✅ yes	✅ yes	✅ yes	✅ yes	✅ yes	❌ no
Git	✅ yes	✅ yes	✅ yes	✅ yes	✅ yes	✅ yes	✅ yes	❌ no
Subversion (svn)	✅ yes	❌ no	❌ no	❌ no	❌ no	❌ no	❌ no	✅ yes
Mercurial (hg)	✅ yes	❌ no	❌ no	❌ no	❌ no	❌ no	❌ no	❌ no
Bazaar (bzr)	❌ no	❌ no	❌ no	❌ no	❌ no	✅ yes	✅ yes	❌ no
Private projects in free plan	✅ unlimited	✅ unlimited	✅ yes	✅ yes	✅ yes	❌ no	✅ yes	✅ yes
Members in private proj. in free plan	✅ unlimited	✅ unlimited	🟠 max 5	?	?	❌ no	✅ unlimited	✅ unlimited
Story points in free plan	✅ yes	✅ yes	❌ no	?	?	❌ no	❌ no	❌ no
Answer via email	✅ yes	✅ yes	✅ yes	✅ yes	?	?	?	❌ no
Workboards (Kanban)	✅ yes	✅ yes	✅ yes	✅ yes	?	?	?	❌ no
Task supports parents and children tasks	✅ yes	❌ no	❌ no	❌ no	?	?	?	❌ no
Task preserves URL even if the project changes	✅ yes	❌ no	❌ no	❌ no	?	✅ yes	✅ yes	❌ no
Task can be created without a project	✅ yes	❌ no	❌ no	❌ no	?	❌ no	❌ no	❌ no
Bug can affect multiple projects	✅ yes	❌ no	❌ no	❌ no	?	?	?	❌ no
Calendar	✅ yes	❌ no	❌ no	❌ no	❌ no	❌ no	❌ no	❌ no
Chat (basic)	✅ yes	❌ no	❌ no	❌ no	❌ no	❌ no	❌ no	❌ no
Question/Answers (basic)	✅ yes	❌ no	❌ no	✅ yes	❌ no	❌ no	❌ no	❌ no
Docker registry 4 every repo	❌ no	✅ yes	✅ yes	✅ yes	?	?	❌ no	❌ no
Wiki	✅ yes	✅ yes	✅ yes	✅ yes	?	?	?	❌ no
CI/CD	✅ yes	✅ yes	✅ yes	?	?	?	?	❌ no
CI/CD can run on every single commit	✅ yes	❌ no	❌ no	?	?	?	?	❌ no
Webhooks for commits	✅ yes	✅ yes	✅ yes	✅ yes	?	✅ yes	✅ yes	❌ no
Webhooks for tasks	✅ yes	✅ yes	✅ yes	✅ yes	?	✅ yes	✅ yes	❌ no
Pastebin	✅ yes	❌ no	❌ no	✅ yes	?	?	?	❌ no
Tasks can be visible only to me	✅ yes	❌ no	❌ no	❌ no	❌ no	❌ no	❌ no	❌ no
Task description is collaborative	✅ yes	❌ no	❌ no	❌ no	?	❌ no	❌ no	❌ no
Code in proposals is collaborative (e.g. code in merge request)	✅ yes	🟠 no	🟠 no	🟠 no	?	?	?

Some key differences between Phorge and other software and services.

License and solutions

GitLab, Launchpad, Phorge and Mantis bug tracker are all free software. This means you have the freedom to study, modify, improve and share them. This means you can:

• self-host these platforms on your own servers (100% data ownership)
• have an on-premise solution (your servers but official assistance)
• find a service provider (someone taking care of everything on their infrastructure)

Bitbucket and GitHub, instead, are proprietary software as a service and this means they take care of everything but you have not the freedom to study, modify, improve and share the platform (you can't install it on your server ecc.).

GitHub, GitLab, Phorge and Launchpad can be used "as a service", provided by their respective companies. Actually Phorge official service does not allow gratis registration to everyone. Anyway, Phorge, GitLab and Launchpad may be used "as a service" by some providers (not promoted from this book).

Source version control

Phorge supports multiple source version control systems: git, Subversion, Mercurial. This feature is quite unique.

Launchpad supports both Bazaar and git.

GitLab and GitHub only supports git.

Code Collaboration systems

Phorge supports a pre-commit review inspired by an evolution of email collaboration (e.g. familiar to contributors of the Linux kernel). It means that contributors can share patches, through a web interface called Differential (activated as default), or using the command line tool Arcanist that can facilitate the upload, the update, and the automatic execution of local "linting" and local unit tests before sharing the patch, using the computational resources available on your local computer to know if the patch follow the guidelines, etc. This pre-commit review supports svn, git and Mercurial, and for all these cases, the patch is designed to be saved as ethereal entity that do not need to touch a real official repository to be discussed, and the patch "lands" the real repository only after it's ready (e.g. approved). Different users as default can actively collaborate on different patches (for example the reviewer can always re-write a received patch). Phorge supports both pre-commit review (with Differential), and post-commit review (with Diffusion Commit Audit). Using the post-commit review, problematic commits can be highlighted as such, for example, commits identified as a regression can be easily recognized from the online git history. Phorge is designed to reach a linear project history in the destination repository, where every code proposal is an idea (it means proposed commits are squashed as default) but can be configured differently.

GitLab, GitHub (that only supports git) are built over merge requests (also known as pull requests). It means contributors should have their own separate repository ("fork"), as it's necessary a repository-2-repository interaction on the same server to accept code proposals, where every code contributor has their own repository, or has direct access to the official repository. Who wants to propose a patch, so, should be the person who owns the "fork" and that person should activate the merge request. The code proposed from a merge request is not supposed to be collaborative, in the sense that other users usually cannot edit it, often including the reviewer that cannot fix / re-write the patch (particularly true if the code proposer worked on the primary branch).

Launchpad is built over merge requests.

Permissions

In Phorge, the privileges of almost every object can be tuned for custom visibility and edit privileges. This feature is quite unique. Example of a custom visibility is having a repository "Editable only by Administrators, and Users in the Security group, and Mario Rossi, but only when Moon is full". You can have global defaults like "Visible to everybody" and "Editable by Trusted Contributors". You can create objects (e.g. Tasks) that are only visible to you, so you can organize your work in private stubs before their publishing. This feature is also used to create secret Passphrases "only visible to me", etc.

In GitHub, GitLab and Launchpad this is limited, so, maybe it's simpler. Anyway you cannot have a public issue on a private repository, and you cannot have an issue that is "Visible only to Mario Rossi", or "Editable only by Trusted Contributors", etc.

In Mantis bug tracker, only Tasks can be hidden. They have only two states: Public and Private (where Private is a fixed list of users).

Permanent deletions

Phorge is somehow paranoid about permanent destruction of objects from the web interface. Usually, objects can be archived, marked as deleted, but not permanently deleted. You may need access to the server command line to do important operations, like repository deletions, etc. The reasons about this choice are explained in the documentation page about Permanently destroying data in Phorge. In this way, normal Administrators cannot do any big mistake from the web interface.

In GitHub and GitLab it's easy instead to completely destroy a repository, if you are an Administrator.

Tasks dependency

Phorge has a very flexible dependency system to declare: What are the parents of this Task? What are the children? Note: plural in both cases. So, you can organize very complex work that involves big multiple departments and projects in a visually understandable way. Example in Wikimedia Foundation: https://phabricator.wikimedia.org/T229015

In any other platforms, this feature is very basic. Usually, you can just have one parent, and multiple children.

In Mantis bug tracker, the system is quite flat, and normally people just don't assign parent/children Tasks. This is handled like an extra attribute and not visually shown as a tree.

Visual Work progress

In Phorge, you can assign "Points" to Tasks. So that, a Task is much more complicated than another one and takes more time, etc. Then, you can assign "Point limit" to Workboard columns. Then, every column shows how are you going, if you are going in burnout. If you close a Task, the progress bar advance by its Point factor and it's visually useful. Also, for each Project, there is an automatic render that shows your "Burnout chart", so that you see you much Open Tasks a project is receiving, how much Tasks are closed over time, to see if your team is efficient or under total burnout etc.

Please add other comparisons.

Other notes

There is also an interesting and quite neutral comparison between Phorge and GitLab, talking also about Bugzilla, GOGS, gitea and Pagure.

You can further read it from the GNOME wiki:

• https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure