Hacker News new | past | comments | ask | show | jobs | submit login

Jumping onto one of the most popular source control platforms is a really good move for KDE, but I'm a bit disappointed to read this. Phabricator is a really excellent piece of software, and seeing large projects like KDE running on it gave me hope that it would have a long life ahead still.

It's 2020 and phabricator still requires users to use an amazingly buggy seperate CLI (arcanist) to create pull requests ('diffs'). Because it is not that widely used, good luck on finding solutions to the many issues you might encounter. The workflow with arcanist also differs in many ways then simply using git.

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)

I can't blame them, GitLab's CI integration is great. Take a look at it:


I've tried to find same in the Blender's phabricator and it doesn't look that they have CI support at all.

Yep. Phabricator kiiiinda has CI through Harbormaster, but it's not well documented and only sorta kinda works, and if I remember right, requires running arcanist commands locally. It's way far behind what other platforms are doing.

Ah, it reminds me of another issue - AWS-type naming (harbormaster, maniphest, phriction, diffusion, differential) I simply can't what are those without clicking them.

The naming style wasn't great, but you get used to it, like anything else. The architecture itself was beautiful; rather than trying to build a single monolithic application, the developers built a federated suite of applications that all shared a common architecture. This made it possible for the developers to treat each Phabricator component as a separate project and also allowed Phabricator administrators to set up a la carte configurations according to the organization's specific needs.

Absolutely, diff (Differential) based patch review is a great workflow for adding changes

Harbormaster works fine, though it requires a million clicks to set up.

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.

There are many high-quality CI platforms that integrate into Git that look great. It doesn't have to be built into a large monolithic platform like GitLab. I feel like this is a bad decision too. You'd think they'd at least move to Sourcehut.

I enjoyed using Phabricator but the barrier to entry is too high for a community project like KDE which needs every new developer it can get. Just a few small hurdles are enough to put people off.

I actually just wanted to replace an icon size dropdown (pretty dumb idea if you ask me) with a slider and a preview of the size of the icon. The reason why I gave up is that I couldn't find the original repository. For some reason the KDE team decided to only link at https://invent.kde.org/ and never actually specify the actual repository. Heck, even the github mirror doesn't show the link to the real repository. When I search on invent I just find lots of unrelated forks. This wouldn't be a problem if they were actually linking to the damn projects.

Can you point me at any data which supports this? It seems like it should be true, but GHC didn't appear to see a year-over-year increase to contributors when they switched from Phabricator to GitLab in December 2018.

See: https://news.ycombinator.com/item?id=23686803

I added another comment to https://news.ycombinator.com/item?id=23686803 about case studies we hope to do about this. So while we don't have any to point you to today, we hope to have some in the near future.

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.

The workflows of Phabricator, having Tasks as Issues and attaching patches to them is way archaic to how people who are used to Github do things - they fork, make changes, and submit merge requests.

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.

Do you have data to support this claim?

For example, GHC moved from Phabricator to GitLab in December 2018, citing ease of contribution as a major benefit:


As of April 2020 (about a year after the transition), the GHC year-over-year contributor numbers didn't appear to change:


(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?

I'm not the OP. However, speaking from my own experience using Phabricator for the first time: I wanted to send a small pull request that fixed wrong mouse cursors being used on Chromium-based programs. The fix was literally symlinking a couple of files. This issue was on Breeze_Cursors from KDE, by the way.

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.

I can totally relate to this. In fact, just a few months ago I complained here about the steep entry bar for KDE 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.

> 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.

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.

Just to add to this discussion, I work at GitLab and we have it on our roadmap to write some case studies about open source projects using GitLab. It's great to hear people's personal stories with regard to contribution being easier, and we hope that the case studies will serve as another reference for people considering a move to GitLab.

In my view, refocusing the roadmap on only requests from paying customers was possibly the best change I've made for the health and longevity of the project.

Let me say up front that I'm a die-hard fan of Phabricator but not a paying customer. I have no idea how you've managed to build and maintain that project, it's amazing.

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.

Open source projects generally want an exact feature-for-feature copy of GitHub that looks and works exactly like GitHub, except open source.

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.

Okay, fair enough. I'm not a paying customer so I have nothing further to say.

Familiarity of source control tool lowers barriers for new developers coming into the project. For me this is enough reason to move to GitLab.

As someone who casually contributes to various projects, I do find Phabricator a block.

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact