[marceldegraaf]

We've been using Phabricator for a few months, coming from private repos on Github.com. We initially liked it because it "ticked all the boxes" for the features that we needed from a source code and issue tracker. However, we ran into major issues along the way, basically because some of the concepts in Phabricator aren't compatible with our workflow. We decided to switch to Github Enterprise and haven't looked back since.

Some of the issues we had with Phabricator:

1. Phabricator is actually a suite of different applications that do specific things (e.g. source code hosting, issue tracking, project management, ...). Although Phabricator ticked all our feature boxes, some of the components it ships with are very immature and/or don't get a lot of attention from the development team.

2. For some reason the platform as a whole feels like a CRUD layer on top of a data model. The UI and various workflows in the applications are very tightly coupled with the underlying data model. I guess that makes it easy to develop and maintain the various core applications of Phabricator, but it doesn't make for a very user-friendly or usable product.

3. We have ~150 internal repositories, we actively work on ~40 of them at any given time. The source code application doesn't seem intended for that many repositories (e.g. navigating to a specific repository is non-trivial)

4. Phabricator has a fundamentally different approach to "pull requests". It works really nice, but only if you commit to using the Phabricator Way Of Doing Things. However, our team has been working on Github.com for years, and we're so used to the Github-workflow that we couldn't get used to the Phabricator workflow.

In the end Phabricator just wasn't the right tool for us. It definitely has some attractive properties: it's easy to install and upgrade, the command line tools are solid and provide all functionality you need, and it performs extremely well even on a small EC2 instance.

(EDIT: formatting)

[_yy]

> 1. Phabricator is actually a suite of different applications that do specific things (e.g. source code hosting, issue tracking, project management, ...). Although Phabricator ticked all our feature boxes, some of the components it ships with are very immature and/or don't get a lot of attention from the development team.

The features which aren't explicitly marked "experimental" work very, very well in my experience. Especially the code review part, which I find more pleasant to use than Gerrit.

> 2. For some reason the platform as a whole feels like a CRUD layer on top of a data model. The UI and various workflows in the applications are very tightly coupled with the underlying data model. I guess that makes it easy to develop and maintain the various core applications of Phabricator, but it doesn't make for a very user-friendly or usable product.

Have you got some examples? They're hiding the database pretty well IMO, and we haven't had many usability complaints that weren't about minor issues. Many of the experimental features are cumbersome to use though and we've turned off some of them again to avoid confusion.

> 3. We have ~150 internal repositories, we actively work on ~40 of them at any given time. The source code application doesn't seem intended for that many repositories (e.g. navigating to a specific repository is non-trivial)

Have you raised an issue about this? They're very responsive to issues encountered in real-world use and usually decide about feature requests by user demand. I do know that they're working on improving this - the "callsigns" will become optional, for example.

> 4. Phabricator has a fundamentally different approach to "pull requests". It works really nice, but only if you commit to using the Phabricator Way Of Doing Things. However, our team has been working on Github.com for years, and we're so used to the Github-workflow that we couldn't get used to the Phabricator workflow.

Their way of doing (or actually, not doing) pull requests is the most important feature of Phabricator. Their approach scales much better than the traditional style and is - in my opinion - the most important reason to choose Phabricator over Github-style tools. This might not matter for small projects, but in a company, it sure does.

Someone wrote it up quite nicely there: http://cramer.io/2014/05/03/on-pull-requests/

[marceldegraaf]

Hi, sorry for my late reply, apparently I'm not notified of responses to comments :-).

1. That's true; the non-experimental parts of the suite are mature and work really well.

2. This was most apparent in experimental features like Harbourmaster/Drydock, where you need a lot of clicking around to configure a basic build setup. Granted, that didn't apply as much to the core applications, but we didn't find those very user friendly too. The task detail screen in Maniphest, for example, is super-cluttered with all kinds of labels, links, and text in the main panel of that screen. Also, the fluid layout in Maniphest makes it hard to read task descriptions/comments because lines of text get very long.

3. No, we didn't, because we were going to switch away to Github Enterprise anyway. You're right about responsiveness of the team, we noticed that too, and that's really nice.

4. Exactly, code review is how Phabricator started and I can definitely see merits in their approach. However, we aren't interested in changing the core workflow of 15 engineers just because it's theoretically a better way of doing code review. We're getting actual work done just fine with Github's PR system, despite the flaws it has, and that was one of the main motivations to go back to Github (Enterprise, in this case).

Like I said earlier: I think Phabricator is actually a very nice tool and I can see how it works really well for large teams that are willing to commit to the code review style. It just wasn't the right tool for us :-).