ComfyUI ecosystem research: sources, proxies and defensible conclusions
Repository activity, model downloads and product announcements describe different parts of the ComfyUI ecosystem. None is automatically a count of active people or revenue. This research method separates source observations from proxies and explains what evidence would be needed for a stronger conclusion.
Ask a question the evidence can answer
Choose a defined question such as which workflow types are documented, which installation routes are maintained or which dependencies a project needs. State a date and scope. A collection of examples cannot answer how many unique people actively use the entire ecosystem.
Separate software capability from adoption. A repository documenting a model integration supports a statement that the integration is described there, subject to its stated requirements. It does not establish that every installation uses it or that this site has executed it successfully on independent hardware.
Maintain a source register
For each observation, record the primary URL, publisher, component version and retrieval date. Attach the particular claim being supported. Prefer maintainer documentation, official model cards and research papers over a promotional summary when explaining a technical capability.
Preserve the distinction between a source statement and an inference. Repository stars, package downloads and public discussion are possible activity indicators, but their populations overlap and can include inactive accounts or repeated downloads. Do not add such counts into a unique-user estimate without a defensible deduplication method.
Require a denominator for quantitative claims
Before reporting a percentage, define its numerator, denominator and collection process. Explain missing observations and selection bias. A voluntary response from a small community does not automatically represent all users, and a trend in one platform does not establish a trend across the whole market.
For performance comparisons, preserve workload, environment, measurement boundaries and unsuccessful attempts. Keep upstream benchmarks separate from independently executed tests. If no qualifying run record exists, report that absence rather than filling a chart with illustrative values that resemble measured results.
Publish conclusions with their limits
Use a qualitative component map when evidence supports relationships but not market size. Describe application, extension, model and hosting layers separately. Attach unresolved questions to the relevant layer so a future review can collect the missing evidence without rebuilding the entire argument.
This revision offers no estimated total addressable market, active-user count or revenue forecast. Those conclusions require additional auditable data and an appropriate method. Readers can still use the source register to evaluate compatibility, provenance and operational requirements. A correction should preserve the route and explain the evidence change rather than quietly replacing one unsupported number with another.