No way to create pull requests from the UI.
The UI itself is amazingly slow and clunky (wait for all the files in the diff to load before being able to click anything).
On top of that it has fallen way behind on simple third party integrations that GitHub and gitlab enable.
I would pick gitlab over phabricator any day.
(I have been a former KDE contributor)
https://invent.kde.org/network/kaidan/-/pipelines/25364
I've tried to find same in the Blender's phabricator and it doesn't look that they have CI support at all.
It can trigger automatically for new commits or new revisions.
Gitlab is much better at the CI part, though, but significantly worse for code review.
Another thing that we hear from people considering a move to GitLab is that they really like how fast GitLab moves (one release per month!), and how it works with the community to keep improving the product. I recently joined as the Sr. Open Source Program Manager as part of the Community Relations team, and we're thinking a lot about how to continue to improve the experience for our community.
Paying customers hire developers, and developers always, always create pressure within their organizations to use the tools and software that the developers are most familiar with. A few developers in this thread have mentioned some things they've struggled with; I've spent a lot of hours reading Phabricator documentation, sussing out Conduit, trying to learn how to use the whole system well, and there are still lots of gaps in my knowledge. When Phabricator becomes too different from the workflows that developers are accustomed to elsewhere, and it isn't immediately obvious that those differences make it better than the alternatives, then they're going to pressure their organizations to not use Phabricator.
Developers furthermore are always looking for ways to build their resumé. The further away Phabricator falls from being used in big, well-known, popular software projects, the more it becomes a hindrance to resumé-building. A developer can add GitHub or GitLab familiarity to their resumé for extra credit, and GitHub public profiles are a good way to say, "Hey look, I write and ship code on a regular basis". If I'm trying to get hired, and I want to learn about integrating CI, I might have to choose between GitHub Actions or Harbormaster. One of those is far, far more valuable for resumé-building than the other.
I can't argue with your focus on paying customers, but if your developer community isn't big and healthy, your paying customers will eventually not be, either.
If Phabricator was this, there would be no reason for paying customers to ever choose it over GitHub, because paying customers generally do not care if a solution is open source or not.
But the bigger impact of this change was not a product impact at all: it was that interacting with paying customers is something I generally enjoy and feel good about, and interacting with open source users is something I generally hated and felt miserable about.
For whatever reason, Phabricator attracted a large number of users who wanted to argue with me about every technical decision, insist that whatever feature they wanted should be the highest upstream priority, suggest I should pay them for their "valuable suggestions" because they are an important CEO, take offense when I asked them to please please please read the documentation and provide reproduction instructions, bump every open task asking for status updates, etc. This stuff had a huge net cost to the project and only got worse over time as the project grew.
Writing off open source installs allowed me to stop dealing with all of this.
If you want to solicit outside contributors you pretty much have to support this model or you will lose a sizable fraction of potential devs.
For example, GHC moved from Phabricator to GitLab in December 2018, citing ease of contribution as a major benefit:
https://twitter.com/bgamari/status/1069047550727069696
As of April 2020 (about a year after the transition), the GHC year-over-year contributor numbers didn't appear to change:
https://twitter.com/evanpriestley/status/1245817419441926144
(I'm not sure this is a fair comparison, and am not aware of other possible changes to GHC during those years, and bear in mind that I'm a highly biased party.)
Can you point at a project which made a switch like this and saw an actual significant change in contributions or contributors afterward?
It took me half an hour to read the KDE documentation on how to contribute, then set-up my workflow, learn how to use arcanist; to only then, submit the pull request. Thankfully my pull request was accepted right away, because had the developers requested code changes I would probably have to spend some more time having to deal with arcanist again.
I'm not gonna lie, having to use a totally different workflow from the ones I was used to (Github, Gitlab and the like), just to submit a small change, was a little frustrating. Ah, one more annoyance (although not related to code): The two-factor authentication system used in KDE's Phabricator is _so stupid_ that I wish I hadn't seen it.
Couldn't the same argument be made for having to learn a language in order to even contribute code to a project? Learning how to collaborate using different systems isn't really different than having to learn different languages, conventions, or code styles to contribute to different projects.
Now, ever since moving to Gitlab not only was I able to successfully contribute, but I effectively became a co-maintainer of one of the projects. We also had some pull requests from some "hit and run" coders previously unknown to the project.
It's 2020, nobody wants to waste hours to learn how to contribute to an open source codebase. I can't think of a bigger deterrent than a complex, unorthodox approach that KDE had previously used.
GitLab/GitHub are ubiquitous (let's face it, learning one of them is learning both of them), so contributing to any project that uses either (or a clone) is simple.
Something dramatically different with custom tooling and flows is a barrier of entry, that might discourage one from jumping in.