6 ms·

Phabricator[0]: code review/CI solution from Facebook. My company uses it, open development has since been halted by Facebook and we're effectively on abandonwa

Phabricator[0]: code review/CI solution from Facebook. My company uses it, open development has since been halted by Facebook and we're effectively on abandonware. Flow[1]: JavaScript typing system from Facebook. My company uses it, open development has since been halted by Facebook so we're effectively on abandonware. EDIT: React: Javascript framework from Facebook, my company uses it, and while it has its warts it works pretty well all things considered and Facebook has continued to support and evolve it over time! For all I know Sapling is fantastic and will be developed for years to come. But personally I can't help but feel "once burnt, twice shy" (or in this case, twice burnt once shy). I'd be happy to be wrong here because ergonomics of Git are really frustrating in many places. 0: https://www.phacility.com/phabricator/ https://www.phacility.com/phabricator/ 1: https://flow.org/ https://flow.org/

smeenai 4y ago
Disclaimer: I work at Facebook. Your thought process is completely fair, but just to clarify: Phabricator was never open-sourced by Facebook. The main engineer behind Phabricator (Evan Priestley) left Facebook to create Phacility and open-source Phabricator; that was never a Facebook product.
- mitrandir77 4y ago
  Phabricator was opensourced by Facebook. But most of it life as an opensource product is was actively maintained by Phacility.
- tomelliott 4y ago
  Pretty sure that isn’t true. If memory serves, Evan open sourced Phabricator at Facebook back in 2010 or 2011, then quit to work on it full time. Shortly after (months, years?) the internal version of Phabricator diverged from the now not FB managed or stewarded OSS one. However I think it is fair to say, assuming my memory is correct, that Phabricator was open sourced by Facebook at a very different time, before the company really committed to supporting open source projects. At that time it was more ‘if an individual engineer wanted to then go for it’ rather than there being any formal process or consideration of longer term commitments. That changed fairly shortly afterwards with the creation of the OSS team. I remember someone transitioning to the newly formed team and moving from Dublin to London to do so in ~2012, as we became housemates :)
  - lelandfe 4y ago
    https://secure.phabricator.com/book/phabflavor/article/project_history/ https://secure.phabricator.com/book/phabflavor/article/proje... > left Facebook in April [2011], and shortly after, we open sourced Phabricator
    - tomelliott 4y ago
      Fair enough! Although if Evan had access to the codebase after he was an employee and if it was the Facebook codebase that was open sourced then Facebook were involved. The original post sounded (to me) like the OSS code wasn’t the same as the FB code. I think that just backs up my point that it was the Wild West back then in terms of individual decision making.
shp0ngle 4y ago
It’s not that hard to convert Flow code to TypeScript code.
lolinder 4y ago
It's worth pointing out: React[0]: JavaScript front-end web framework from Facebook. For good or ill, the most widely-used web framework in the world. Not to say that Facebook will maintain Sapling, but React does stand as proof that they're not incapable of carrying an open source project to the finish line. [0] https://github.com/facebook/react https://github.com/facebook/react
- aliveli 4y ago
  Don't forget projects like PyTorch, Presto, etc.
  - lolinder 4y ago
    Oh, right! I forgot PyTorch was originally Facebook (and it's not under their umbrella anymore).
    - voz_ 4y ago
      We still work on it tho :)
  - TillE 4y ago
    zstd is fantastic, though I suppose it's not the sort of thing that particularly needs ongoing active maintenance.
    - deleted 4y ago
      [deleted]
    - MikusR 4y ago
      You would think that, but then you look at its release notes.
- xctr94 4y ago
  I have my doubts as to whether they can be a good citizen of the open-source community and respect the developers relying on their tools. I routinely see bugs marked “won’t fix” and nonsensical new features in the React Native ecosystem.
vfclists 4y ago
If you think Facebook are bad when it comes to abandoning software projects, try Microsoft.
- xctr94 4y ago
  Google isn’t far behind either. Perhaps corporate-owned open-source ecosystems weren’t a great idea.
  - palisade5132 4y ago
    I thought one of the main open-source's selling point is the fact you can fork it and maintain it even when the original author abandons it. Any alternative I can think of is a community-owned open-source, which probably wouldn't often work due to limited resources and no initial funding or a corporate-owned closed-source, which once abandoned is dead for good.
- mariusmg 4y ago
  Still missing Clippy ?
renewiltord 4y ago
Interesting. FB also open-sourced Thrift and then promptly had fbthrift diverge instantly. Overall, I'm glad they do these things, though since it is better to have this code accessible than absent. Good on them!
- Shish2k 4y ago
  HHVM is an interesting data point too - kept PHP compatibility for as long as there were significant open-source users (eg wikipedia), but after PHP7 caught up with a lot of the performance gains, meaning there was little reason to use HHVM in PHP-compatibility mode, they then went off in their own direction with Hacklang (which is still actively developed) to get all the benefits of being PHP-like without the drawbacks of being PHP-compatible.
  - tambourine_man 4y ago
    >get all the benefits of being PHP-like without the drawbacks of being PHP-compatible I have a hard time understanding the benefit of using a language that’s almost like a very popular one, but not quite.
    - Shish2k 4y ago
      PHP has some benefits to its design that the vast majority of other languages don’t — deployment is as simple as “stick a .php file on in your website folder”, hitting the “refresh” button gets you the latest code with no “build” or “restart server” step, it’s all stateless shared-nothing so you won’t have data from one request changing the behaviour of another request, etc. But the implementation has a lot of drawbacks - the language is painful, typing is bolted-on and still incomplete after years of work (eg there are no typed arrays), the standard library is an inconsistent mess thanks to its origins of “take several other language’s standard libraries and duct-tape them together”, etc.
      - tambourine_man 4y ago
        Yes I’m well aware of the problems. I just seems to me that being PHP-like but incompatible is much more confusing than useful.
Shish2k 4y ago
The nice thing is that this is a client that works with vanilla git servers - if you switch to using it now, best case, you get a lifetime of good ergonomics; worst case, you get a few months of good ergonomics before something breaks that upstream doesn’t want to fix, and you go back to using the vanilla git client.
combyn8tor 4y ago
For me it was Parse.
golergka 4y ago
To be fair, Flow wasn't abandoned just out of the blue, it was surpassed by Typescript to the point of becoming completely pointless.
jsiepkes 4y ago
Phabricator has a fork which is still developed: https://phorge.it/ https://phorge.it/
deleted 4y ago
[deleted]
paradite 4y ago
Does Facebook/Meta still use Phabricator internally?
- aliveli 4y ago
  Yes

smeenai 4y ago

Disclaimer: I work at Facebook. Your thought process is completely fair, but just to clarify: Phabricator was never open-sourced by Facebook. The main engineer behind Phabricator (Evan Priestley) left Facebook to create Phacility and open-source Phabricator; that was never a Facebook product.

mitrandir77 4y ago
Phabricator was opensourced by Facebook. But most of it life as an opensource product is was actively maintained by Phacility.
tomelliott 4y ago
Pretty sure that isn’t true. If memory serves, Evan open sourced Phabricator at Facebook back in 2010 or 2011, then quit to work on it full time. Shortly after (months, years?) the internal version of Phabricator diverged from the now not FB managed or stewarded OSS one. However I think it is fair to say, assuming my memory is correct, that Phabricator was open sourced by Facebook at a very different time, before the company really committed to supporting open source projects. At that time it was more ‘if an individual engineer wanted to then go for it’ rather than there being any formal process or consideration of longer term commitments. That changed fairly shortly afterwards with the creation of the OSS team. I remember someone transitioning to the newly formed team and moving from Dublin to London to do so in ~2012, as we became housemates :)
- lelandfe 4y ago
  https://secure.phabricator.com/book/phabflavor/article/project_history/ https://secure.phabricator.com/book/phabflavor/article/proje... > left Facebook in April [2011], and shortly after, we open sourced Phabricator
  - tomelliott 4y ago
    Fair enough! Although if Evan had access to the codebase after he was an employee and if it was the Facebook codebase that was open sourced then Facebook were involved. The original post sounded (to me) like the OSS code wasn’t the same as the FB code. I think that just backs up my point that it was the Wild West back then in terms of individual decision making.

shp0ngle 4y ago

It’s not that hard to convert Flow code to TypeScript code.

lolinder 4y ago

It's worth pointing out: React[0]: JavaScript front-end web framework from Facebook. For good or ill, the most widely-used web framework in the world. Not to say that Facebook will maintain Sapling, but React does stand as proof that they're not incapable of carrying an open source project to the finish line. [0] https://github.com/facebook/react https://github.com/facebook/react

aliveli 4y ago
Don't forget projects like PyTorch, Presto, etc.
- lolinder 4y ago
  Oh, right! I forgot PyTorch was originally Facebook (and it's not under their umbrella anymore).
  - voz_ 4y ago
    We still work on it tho :)
- TillE 4y ago
  zstd is fantastic, though I suppose it's not the sort of thing that particularly needs ongoing active maintenance.
  - deleted 4y ago
    [deleted]
  - MikusR 4y ago
    You would think that, but then you look at its release notes.
xctr94 4y ago
I have my doubts as to whether they can be a good citizen of the open-source community and respect the developers relying on their tools. I routinely see bugs marked “won’t fix” and nonsensical new features in the React Native ecosystem.

vfclists 4y ago

If you think Facebook are bad when it comes to abandoning software projects, try Microsoft.

xctr94 4y ago
Google isn’t far behind either. Perhaps corporate-owned open-source ecosystems weren’t a great idea.
- palisade5132 4y ago
  I thought one of the main open-source's selling point is the fact you can fork it and maintain it even when the original author abandons it. Any alternative I can think of is a community-owned open-source, which probably wouldn't often work due to limited resources and no initial funding or a corporate-owned closed-source, which once abandoned is dead for good.
mariusmg 4y ago
Still missing Clippy ?

renewiltord 4y ago

Interesting. FB also open-sourced Thrift and then promptly had fbthrift diverge instantly. Overall, I'm glad they do these things, though since it is better to have this code accessible than absent. Good on them!

Shish2k 4y ago
HHVM is an interesting data point too - kept PHP compatibility for as long as there were significant open-source users (eg wikipedia), but after PHP7 caught up with a lot of the performance gains, meaning there was little reason to use HHVM in PHP-compatibility mode, they then went off in their own direction with Hacklang (which is still actively developed) to get all the benefits of being PHP-like without the drawbacks of being PHP-compatible.
- tambourine_man 4y ago
  >get all the benefits of being PHP-like without the drawbacks of being PHP-compatible I have a hard time understanding the benefit of using a language that’s almost like a very popular one, but not quite.
  - Shish2k 4y ago
    PHP has some benefits to its design that the vast majority of other languages don’t — deployment is as simple as “stick a .php file on in your website folder”, hitting the “refresh” button gets you the latest code with no “build” or “restart server” step, it’s all stateless shared-nothing so you won’t have data from one request changing the behaviour of another request, etc. But the implementation has a lot of drawbacks - the language is painful, typing is bolted-on and still incomplete after years of work (eg there are no typed arrays), the standard library is an inconsistent mess thanks to its origins of “take several other language’s standard libraries and duct-tape them together”, etc.
    - tambourine_man 4y ago
      Yes I’m well aware of the problems. I just seems to me that being PHP-like but incompatible is much more confusing than useful.

Shish2k 4y ago

The nice thing is that this is a client that works with vanilla git servers - if you switch to using it now, best case, you get a lifetime of good ergonomics; worst case, you get a few months of good ergonomics before something breaks that upstream doesn’t want to fix, and you go back to using the vanilla git client.

combyn8tor 4y ago

For me it was Parse.

golergka 4y ago

To be fair, Flow wasn't abandoned just out of the blue, it was surpassed by Typescript to the point of becoming completely pointless.

jsiepkes 4y ago

Phabricator has a fork which is still developed: https://phorge.it/ https://phorge.it/

deleted 4y ago

[deleted]

paradite 4y ago

Does Facebook/Meta still use Phabricator internally?

aliveli 4y ago
Yes