In short, the post confirms that work on Flow is no longer going to be prioritized unless it aligns with Facebook's internal uses. So, use Typescript instead. I personally really like this post. I...
In short, the post confirms that work on Flow is no longer going to be prioritized unless it aligns with Facebook's internal uses. So, use Typescript instead.
I personally really like this post. I think having internal-use open source projects is great and I'm glad they're both keeping it open source AND admitting the project is not well maintained from an external perspective. Especially when there are alternatives available.
The projects I worked on at Google were similar. They were open source but we struggled to accept patches from the outside because first priority was not breaking internal customers. This...
The projects I worked on at Google were similar. They were open source but we struggled to accept patches from the outside because first priority was not breaking internal customers. This effectively meant that outsiders couldn’t help much with most of what needed to be done to accept a patch. In some cases language changes required doing migrations that required submitting hundreds of patches to other people’s projects.
it could work the other way too, when a change was easier for Google but harder for others.
For changes to outside-controlled open source code coming in, Google was sometimes pretty far behind the outside world as a result of the large migrations that needed to be done. But if the project is controlled by Google then another option is just to decide it’s not worth accepting the change.
In short, the post confirms that work on Flow is no longer going to be prioritized unless it aligns with Facebook's internal uses. So, use Typescript instead.
I personally really like this post. I think having internal-use open source projects is great and I'm glad they're both keeping it open source AND admitting the project is not well maintained from an external perspective. Especially when there are alternatives available.
The projects I worked on at Google were similar. They were open source but we struggled to accept patches from the outside because first priority was not breaking internal customers. This effectively meant that outsiders couldn’t help much with most of what needed to be done to accept a patch. In some cases language changes required doing migrations that required submitting hundreds of patches to other people’s projects.
it could work the other way too, when a change was easier for Google but harder for others.
For changes to outside-controlled open source code coming in, Google was sometimes pretty far behind the outside world as a result of the large migrations that needed to be done. But if the project is controlled by Google then another option is just to decide it’s not worth accepting the change.