Clarify what the Github Integration is and the trajectory/goals of this project / hey-api

[johnpyp]

It's great to see a fresh breath of air go into the openapi-typescript-codegen codebase, and with the additions of recommendations in various projects (like the deprecation notice, FastAPI) pointing to this one as the defacto successor, there's an implied responsibility to the ecosystem.

For that reason, I'd like some clarification on what the intention is with the github integration, and whether or not it's tied to business endeavors or also a completely open-source, free part of the tool... building a backend "service" component of an open source tool always raises the red flag in my head of "this might be starting to get monetized or start feeding into some business incentives I'm not aware of". On the other hand, many open source projects provide this kind of thing completely strings attached and no business incentive or upsell behind it, which is awesome.

Basically, some clarity on the governance and trajectory of the project going forward would be great.

[mrlubos]

That's a good question @johnpyp, and perhaps this should be converted into a discussion. I agree with the responsibility statement, which is partially why we started doing the most opinionated changes early. It will be much harder to make sweeping changes if this package becomes heavily used.

In terms of trajectory, that remains to be seen. The current objective is to build a suite of tools for managing API interactions as described on the About page. Just like TanStack Query owns your data store layer, Hey API aims to own the API request layer.

Of course, as you start building out tools other companies benefit from, it makes sense to explore monetising them. That's what Pydantic is doing for example with their platform. GitHub integration is the first stab at that for Hey API. We might try other avenues later, but the integration is a problem I want to solve either way. If it turns out it's valuable enough for others to pay, great. If not, open sourcing it is always an option (way harder to go the opposite way!)

There are no specific plans beyond that today. This package will always be open source. Other products we come up with might not be.

What do you think?

P.S.

many open source projects provide this kind of thing completely strings attached and no business incentive or upsell behind it

Did you mean no strings attached? Can you provide an example you had in mind?