[aaviran]

As a quite disappointed user of Gitlab (due to issues raised here, e,g, CE vs EE and the Ruby infrastructure), has anyone had experience with both? I understand that Phabricator is a more "complete" solution, but how do they compare in the core features that they both share?

Also, do they pride themselves for writing this in PHP? I consider this an anti-feature, but this might be highly opinionated.

[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 :-).

[_yy]

> Also, do they pride themselves for writing this in PHP? I consider this an anti-feature, but this might be highly opinionated.

I'd prefer it to be written in something else, too, but - the Phacility team are ex-Facebook developers. If anyone knows how to use PHP, it's them. They built their own, extensive web application framework on top of it (which is a remarkable achievement for itself). Phabricator is one of those rare examples that you can, in fact, write excellent code in PHP.

On top of that, they're running a bug bounty with generous payouts: https://hackerone.com/phabricator

[busterarm]

I'm primarily a Ruby developer, but my current gig has me working exclusively in PHP (and worse yet, Wordpress). PHP as a language is actually pretty stellar these days. There are things about it that I dislike, but there has been a lot of recent work put in to improving the language. I'm always finding nice features.

Really the place that PHP is lacking is on the tooling/ops side of the projects built on top of it. A lot of what I have to work with still seems to be 15 years old. That said, it's getting better and other peoples' preferred tools have their share of problems as well.

[rawfan]

> A lot of what I have to work with still seems to be 15 years old.

Like what?

[busterarm]

Ops practices of WordPress hosting companies. Pantheon is one of the few exceptions to this, so props to them.

Management panels of hosting companies.

UltraDNS's website.

Salesforce.

[VeilEm]

> I understand that Phabricator is a more "complete" solution, but how do they compare in the core features that they both share?

I think GitHub is prettier, but having tasks separate from repos and having tasks be as sophisticated as they are in Phabricator and having such a better pull requests system, it doesn't matter? GitHub has to dumb down the user interface on their product to appeal to the least common denominator and maintain their growth. Phabricator is for projects where people care enough about their projects to learn the UI so they can get things done.

> Also, do they pride themselves for writing this in PHP?

As a user I doubt you're going to find your self caring about how it's written.

[pekk]

As a user of a self-hosted web service, how it's written affects details about the pain of deployment and administration. How it's written also affects whether it has satisfactory performance and how many nasty security problems are waiting to be discovered.

Not everyone can afford to be completely blase about their source control system going down or getting defaced.

[_yy]

The Phacility guys know how to PHP. They used to work at Facebook. I don't like PHP either, but I trust the developers in this case.

Gitlab had its fair share of vulnerabilities, too, despite being written in Ruby. It's about the developers, not the language.

Have a look at their bug bounty program: https://hackerone.com/phabricator

[rodgerd]

PHP apps are a hell of a lot easier to keep up-to-date than the unholy hell of Rails apps, especially when you discover developers have started locking dependencies to old gems with known security issues.

[aidenn0]

Phabricator is super easy to maintain. The out-of-the-box experience is better than any complete solution I've tried, including gitlab.

That being said, just like any other fairly complete solution, it's quite opinionated about the right way to do things, and it's very different from github or gitlab. In particular, since it is not tied to git, it duplicates some of git's functionality in its own tools. In many ways I find those tools to be better than what git uses (arcanist just seems more well thought-out from a UI perspective), but it is a learning curve.

If you are happy with svn or hg, and don't want to have to switch to git, Phabricator is a no-brainer. If your team is a bunch of super-advanced git users, they may not like having to learn a different way of doing things.

[mintplant]

A note - the Phabricator core team have been reticent in merging changes or features that they don't themselves depend on upstream. If you need anything that isn't offered out of the box or on the roadmap, be prepared to maintain your own fork of Phabricator indefinitely.

[neandrake]

I started looking into GitLab and Phabricator around August/September 2014 for my company. My criteria was primarily based around something to assist with code review. Ultimately I went with Phabricator for several reasons:

1. Supports Mercurial - our repositories are currently in mercurial, and using any other tool would require switching to git (which we seriously considered while looking at tools).

2. Simple to maintain - if you have experience setting up other web applications based around LAMP, this is essentially very similar. The web interface even indicates setup issues to admins, from things which can cause issues to performance configurations in things such as MySQL and PHP.

3. The code review interface was more intuitive for myself and other engineers. From the command-line tool (Arcanist) to how it's conveyed to the user in the web interface. It did take a little time to fully comprehend and implement the process for using, but since implementing in Feb. of last year, after around 4 months we had near 100% adoption by the engineering department. The GitLab/GitHub interfaces I've found to not be organized intuitively -- the lifetime of an issue/changes seems (seemed?) more social-based and intermized where in Phabricator an Issue/Task is almost separate from the changes which can go into it, though they reference eachother easily.

>Also, do they pride themselves for writing this in PHP? I consider this an anti-feature, but this might be highly opinionated.

I had the same reaction at first (thought I wouldn't say it's pride?). In fact the first time I looked at Phabricator (~2012) I totally dismissed it for three reasons:

1. Written in PHP

2. Mentions pokemon on the front page

3. Marketed as "collection of open source web applications"

These led me to believe that it was at most some PHP glue some students hacked together to get different unrelated applications to play together. This conclusion is entirely wrong. I've since changed my mind about PHP - biased from earlier experiences there's no reason to think a reliable/stable application couldn't be built on it. Phabricator (I believe) started as an internal application at Facebook which has since become its own company. The code is very well organized (I've contributed some small changes), and there are some very bright people working on the project - I get the vibe that they genuinely want to solve the right problems rather than checking features off a list. There are very few dependencies on other libraries unless you specifically decide to enable extra features, and even then there's some support/documentation there to assist. Despite the light-hearted humor (see pokemon) that is a staple of the software (unless you enabled serious-business mode), the project is designed and developed by highly capable, quality professionals.

I couldn't have been happier going with Phabricator over GitLab.