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

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.

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