Flow-typed might have been a mistake

Leigh Silverstein
Netscape
Published in
5 min readMar 27, 2017

Flow-typed is the simple but versatile facebook backed approach to loading flowtype definitions. Thousands of people use either the flow-typed cli tool or the definitions within on a daily basis, and it has a healthy level of contributions from community members across the world. Personally, it’s been a tremendous asset, and I’m delighted every time I find a new definition that I don’t have to stub out with a simple any or Object declaration.

And yet, something feels stale about the flow-typed project. How often are old libraries updated to use the latest flowtype features. How many libraries are taking advantage of new types like $ObjMapi, or $ObjMap? And yes, there are new contributions every week, but are there enough contributions? And maybe this is the real test: Is the gap between flow-typed and typescript’s own DefinitelyTyped shrinking?

This is the pulse report provided by github. It’s a simple look at pull requests and issues. Basically, there is about 10x more activity on DefinitelyTyped than flow-typed. Ideally I would have liked to have seen these pulse reports at different times to see the growth rate of flow-typed contributions, but github doesn’t appear to offer that yet.

We know that there are more typescript users than flowtype users. I can’t speak to whether one is better than the other, but typescript certainly has been around longer. Regardless of the number of users of both type systems, I believe there is still something damning about the ratio of contributions given that flow-typed has far more low hanging fruit than DefinitelyTyped. There are lots of libraries that have not been added to flow-typed yet, and no one seems overly determined to do it.

Now it’s quite possible that given the number of flowtype users, the packages they rely on, and some other combination of reasons, that flow-typed is an incredible success story, and it is actually the perfect repository to manage community contributions to flowtype definitions.

But I don’t think that’s the case. I think that flow-typed represents the standard solution to building up package definitions for a type system, when what they needed was a much more aggressive approach. In particular, they needed a bigger carrot at the end of the stick. They needed a stronger reason for developers to contribute.

I am admittedly the worst kind of open source developer. I rarely contribute to other projects, and am far more likely to open up an issue than actually solve it myself. I’m happy to write my own open source software and share it with the world, but helping to maintain someone else’s project just hasn’t been in the cards for me. Now that last point is important because it’s probably true for a lot of people.

Developers prefer to ship their own open source solution over fixing someone else’s, and it’s not rocket science why. They have complete control over their own project to do it the way they envision, and if the project is a success, they reap all of the reputation points to be had. On the flip side, contributing to open source projects requires trudging through unfamiliar code with the risk that a fix either won’t be possible, or won’t get merged in.

People do contribute to open source projects. Sometimes the projects are small, popular, and well documented, and other times they’re big, ugly and obscure. If I had to guess, I would say the former gets a lot more contributions than the latter. So what is flow-typed?

Flow-typed is the easiest library in the world to contribute to. Contributions are entirely contained, there’s no sifting through unfamiliar code, and the project is well maintained so there’s a high likelihood of pull requests getting merged in. But I haven’t contributed yet. I am huge flowtype fan, and I have written type definitions for libraries that do not exist in the flow-typed repo, but I just couldn’t be bothered to contribute. I know I’m far from the ideal open source developer, and hundreds of people have and will continue to make contributions, but I’m not one of them, and people like me won’t, and there might just be a lot of people like me.

In my mind, there are two general problems with flow-typed. The first is a lack of novelty. DefinitelyTyped already exists, so the task of creating package definitions feels less like an adventure than a chore. The second problem is a lack of contribution impact. It’s a popular library, but it’s not that popular, which means the contributions you make are going to affect less people. It’s also impossible to know if anyone is actually using your definitions, so regardless of how popular flow-typed becomes, there’s never any concrete evidence of contributions actually getting used.

Make no mistake, lack of impact is the core issue with flow-typed. If flow-typed had come out a decade ago, and contributing was just contributing, then flow-typed wouldn’t have a problem. Today we’re surrounded by infrastructure that makes contributing to the open source community, not only more accessible, but more rewarding altogether. Modern package registries and github make it easy to see how many people are benefiting from your work. Flow-typed, being a single repository, makes it impossible to contribute to and enjoy the visible impact that many developers have become accustomed to.

So what is the solution? If flow-typed has a contribution problem, then where do we go from here? Personally, I would like to see more developer-level ownership of library definitions. I want to own both the repo and the npm package for a library’s definitions, and if someone else wants to write their own definitions for that library, than so be it. It will be chaos, there will be confusion, but in place of the tumbleweeds and dust there will be life! Instead of flow-typed being a central repository for definitions, it should be an api to obtain those definitions, where ever they are. And to maintain some semblance of order, there should be a web application not unlike TravisCI that provides badges and catalogues definitions that guarantee a certain quality or complexity of definition.

Or maybe flow-typed is fine, and I should just contribute already. I don’t know.

--

--