Almost everything in this ecosystem is public, and knowing which organisation a repository sits in tells you more than a star count does. It tells you who maintains it, what happens if they stop, and how much weight the thing can bear.
graphprotocol
The protocol itself. graph-node, indexer, indexer-rs, contracts, graph-tooling, docs, and the GIP repository.
Maintained by core developers, changed through the governance process. If something here breaks, it is somebody’s job to fix it. This is the only tier of which that is true.
The GIP repository is worth calling out separately. It is the best design documentation the protocol has, because the rationale sections explain why rather than what, and they are unusually honest about where a mechanism could be gamed. GIP-0051 records the flaw in its own multi-gateway handling, which is not the sort of thing a marketing page volunteers.
edgeandnode
Edge & Node’s own services. gateway, the one most traffic goes through. graphix, the indexer cross-checking software. graph-disputes, tooling for dispute management. local-network, a local graph network for integration testing, which is the thing to reach for before you test anything against the real one.
A company’s repositories rather than the protocol’s. Public, and their roadmap is theirs.
nightswatchhq
Independent work: 89 repositories, of which 43 are nuthatch nests and the rest are tools, data services, gateways and indexing engines. Most of this collection is about what is in here.
Community maintained, which means the honest description is: maintained while somebody cares. That is not a criticism, it is the terms. Read the code, check the last commit, and weight it accordingly for anything long-lived.
Everybody else
Subgraphs live in the repositories of the protocols they index, and the good ones are usually maintained by that protocol’s own team. Graph Explorer will tell you who published a given subgraph, which is the check worth making before building on one.
Reading a repository before you trust it
Cheap checks, in order:
- When was the last commit, and was it substantive or a dependency bump.
- Is there more than one contributor. A single-author repository is a single point of failure regardless of code quality.
- What is the licence. Most of the above is MIT or Apache-2.0; some data services are BUSL-1.1, which is a different proposition if you intend to run it commercially.
- Does the README say what it does not do. The ones that do are, reliably, the better maintained ones.
- Are the issues answered. An issue tracker with unanswered questions from six months ago is telling you the maintenance answer directly.
None of that requires reading the source. All of it is more informative than a star count.