What is the disadvantage then? Well, it is not a product, meaning the external users are not the main target of the project.
The project owners have no incentive to implement anything they don't need themselves, or to fix any bugs that don't impact their own developers. It works fine if your own needs happen to be as close as possible to the ones of the project owner, if you patch stuff you need yourself, and if you don't expect anything from the owner in general.
Especially when I compare Flow and TypeScript (I use the first quite heavily, the second occasionally, filed lots of bug reports for both) the difference between them is quite substantial. For TS Anders Hejlsberg himself answers bug reports, and they listen to what the community wants. In the Flow issues you'll find Facebook employees - but not the actual owners (or if there is one they remain hidden). If the Flow team implements something Github users ask for it's almost always only because the need for it happened to also developed inside Facebook.
I have learned the hard way that "open source" is not sufficient, it should actually also be a product (meaning the owner cares a lot about external opinions). That's most important for things like core libraries and tools like those add-on Javascript type systems, not so important for "leaf node" dependencies in your project, like a library that does something specialized.
There are open source projects that succeed because, aside from being good enough, they also have big corps behind them: TypeScript, Dart, Go, Flow, Kotlin, etc.
But there are also open source (often free software) projects that succeed because they're great and are community-focused and community-supported: Python, Haxe, Julia, etc.
I talked about just that, no? About two of that list specifically, even.
1. wait, there are more axes than just license and productization, and
2. there are other values on those axes that can lead to success (not just open source + productized)
Here are some separate axes I see:
* open source (Apache2, BSD, MIT) vs free software (copyleft (GPL, LGPL))
* corp-backed vs not-corp-backed
* community-driven vs closed-style-development
* core devs have a very solid vision of project direction, vs being more open to change and/or direction taken from contributors
* amount of productization: are the main target users the core devs themselves or external users
* overall quality of the language
Some armchair comments:
+ you risk lock-in by going with corp-backed languages
+ you may see more community involvement with free software projects, whereas more corp involvement with open source
+ high productization often means a very low contributor to user ratio
+ although quality doesn't necessarily win, it sure is nice.
I actually like this about FBOS. I’ve found that I appreciate their vision and direction on the projects I use (React particularly, I love their stewardship there, but also Relay, where yeah issues and suggestions are ignored but that’s fine because I like what the team does and the slow pace). I appreciate that they’re not pulled this way and that way by the community and its whims. That’s why I don’t dig Apollo for example, which seems to be one of these community projects that almost exists more for the community than for the product and tries to be everything to everyone and in the end is not something I appreciate technically or even as a community. Of course Relay docs suck but hey it’s open source! I’d rather use a really strong product like Relay than a weaker product like Apollo, even if it means having to learn some internals.
I think the core document is the Runtime Architecture[0]. After that, it really helps to know ES7 Observables, which I learned by studying the little implementation that's included in Relay[1], but apparently is also at the core of Angular. Then you can either use the runtime architecture directly, or the pre-built React components that are included in Relay. If you use the pre-built components, you need to understand the division of labor between the QueryRenderer[2], which fetches data from your server and puts it in the store, and FragmentContainer[3] which lets you render data from the store with React.
[0] https://facebook.github.io/relay/docs/en/runtime-architectur...
[1] https://github.com/facebook/relay/blob/master/packages/relay...
[2] https://facebook.github.io/relay/docs/en/query-renderer.html
[3] https://facebook.github.io/relay/docs/en/fragment-container....
If you're thinking of companies that are still making shit-tons of money productizing programming languages/environments today, Microsoft is the major player, but it's a battle even they are losing. They just open-sourced .NET, their programming bread and butter.
So it will either die off quickly or be extremely popular and stick around for 20+ years?
VBScript is just as old as PHP and was the primary scripting language on Microsoft products for a solid decade. It was in everything from Office to IIS and still ships with every copy of Windows.
Silverlight is just a framework and was only in active development for 5 or 6 years before being killed off.
You can write a single piece of code that's valid C, C++, C#, and Java but that doesn't make them the same language or subsets of one another.
VBScript started out using the same conventions as VB and a subset of the syntax but it was never really related to it beyond that. There are different flavors of VBScript as well. CScript is a console variant, WScript for window environments, and ASP for IIS Web Development. They're mostly compatible but not entirely. When classes were introduced, they weren't immediately available across all the variations and still aren't IIRC.
It's all very confusing though ultimately I don't think that it contributed to the negative connotations about it. Being associated with VB was ultimately what tainted it.
I imagine, at that scale, that opensourcing is a big win because you can have a proprietary stack, but still hire people that already know it, or won't be reluctant to invest a few years of their life into working on it. You also don't have to pay as much for educating new hires as you would for a totally closed proprietary stack, and new people faster become productive. Hiring contractors that work with that stack on a short notice also becomes easier. For a large co, these kinds of benefits might be more than enough to justify cleaning up the code enough to opensource it.
Creating and maintaining a community around an open source project is a lot of work, and it's understandable if Facebook doesn't want to pour many resources into this particular project, even if they keep it open source.
Because they sometimes get lucky, and people use it. Apple would probably have been just fine with everyone shrugging their shoulders at clang and continuing to use gcc, but clang adoption by others has been of benefit to them anyway, say.
And worst case, there's no major downside to open sourcing language tools.
Worst case is you didn't protect your IP and people get fired because the competition makes the money.
Slack came out with a blog post a few month ago, writing that they use the Hack features on top of HHVM. That is the only one besides Facebook that I know of (there are probably more)
Edit: Source for Etsy using PHP 7 now https://speakerdeck.com/wcgallego/hitting-the-turbo-button-u...
"MediaWiki 1.31 requires PHP 7.0.0 or later. Although HHVM 3.18.5 or later is supported, it is generally advised to use PHP 7.0.0 or later for long term support. "
But MS really did earn a lot of bad will from their dev community who had been pushed to learn yet another framework which ended up dead.
I rarely even use my PC anymore. I basically then it on once a month to download the gigs of updates. It's interesting that Silverlight still listed at the top of optional updates.
There must be a few businesses and schools who bought into the hype and built their internal app on SL.
Unless Facebook's prepared to invest a lot in community-building, Hack and similar FB projects will go the way of VBScript and Silverlight.