As a heavy React Native and Flow user for years, the disadvantage of projects such as those is that they actually are pure and true open source Github projects in the original meaning: The owner produces something for themselves and then shares it.
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.
> 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).
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.
Ah. Ok. Thank you. I see my reply was sloppy --- sorry. It seemed to me that you were suggesting that being open source plus being productized was required for project success, and my thought was:
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.
> (meaning the owner cares a lot about external opinions).
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.
But they recently got better as I found out a few days ago! Yes those docs often miss some critical ideas/apis/etc. and everyone on the issues seems to already know about somehow and how they're supposed to be used.
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.
IMO the only company that has been able to successfully "productize" a language/programming environment is Microsoft, and that is because companies were paying a LOT of money for these tools a decade or two ago.
You're overlooking Borland, Metrowerks, Micro Focus, etc.
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.
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.