Star Counts Are Not Maturity: Picking Open Source You Can Actually Ship

A GitHub star means somebody thought a project looked interesting, usually within a few days of first hearing about it. It is a measure of attention, not of maintenance, stability or fitness for your project. Treating it as a quality signal is how teams end up depending on version 0.0.8 of something.

This post is the counterweight to the rest of this series. Here is what to look at instead, and what we would actually reach for in each category.

Key takeaways

• The version number tells you more than the star count. A project at 0.0.8 is telling you something its README is not.
• Open issues relative to maintainer capacity is the single best health signal you can read in ten seconds.
• Licence is the risk nobody checks until legal does. GPL and AGPL are genuinely different propositions from MIT.
• Bus factor of one is common and often acceptable — but it belongs in a conversation with your client, not in a surprise.
• New tools are worth adopting. The discipline is about placement: internal work first, critical path last.
• Always know your exit. If you cannot name what you would switch to, you have not evaluated it.

Why are stars such a bad signal?

Because starring is free, instant, and happens at the moment of maximum enthusiasm and minimum information. Somebody reads a headline, thinks "that is clever", stars it, and never installs it. The count never goes down when they lose interest.

So a star count is a cumulative record of how many people once found something interesting. It correlates with novelty and marketing far more than with reliability. The projects in this series make the point without any editorialising needed:

Scrapling and Ruflo have star counts of the same magnitude and completely opposite maintenance postures. Semiotic and Pretext differ by a factor of twenty in popularity and in the opposite direction on stability. The signal is noise.

Figures above are as of August 2026 and move constantly — check them yourself rather than trusting a blog post, including this one.

The five-minute evaluation

Before adopting anything, six checks. None take longer than a minute, and together they catch most of what hurts later.

1. Read the version number. A 0.x version is the maintainer telling you the API may change. Believe them. If it is 0.0.x, they are telling you it is an experiment.
2. Check the last release date, not the last commit. A README typo pushed yesterday is not maintenance. When did users last receive something?
3. Divide open issues by contributors. Not the raw count — the ratio. And open three recent issues: are they answered, or are they a graveyard?
4. Count the people with commit access. If it is one, that is your bus factor. Fine for a narrow utility you could fork; different for a framework at the centre of a product.
5. Read the licence file, not the badge. One project in this series claims MIT in its README and ships no licence file at all. That is legally ambiguous, which is worse than a restrictive licence.
6. Check provenance. Is the repository what it claims to be? A re-upload of someone else's project with a sponsor badge added looks identical to the real thing until you read the commit history — we walked through exactly that case.

The licence trap

This is the one that turns into a real problem, because it surfaces late — usually when a client's legal team reads your dependency list a fortnight before launch.

In this series alone: ComfyUI is GPL-3.0, Semiotic is Apache-2.0, Scrapling is BSD-3-Clause, caveman splits MIT and BSL, and one collection has no licence file despite claiming MIT. Five different conversations.

What we would actually reach for

Category by category, the boring answer and when the exciting one is worth it.

• Web scraping. Boring answer: Scrapy, or Parsel alone if you only need parsing. Reach for Scrapling when selector rot or anti-bot handling is the actual cost — it has the best maintenance signals of any young project here.
• Document conversion. Boring answer: Pandoc for well-formed inputs, Docling if your corpus is genuinely scanned. Anydoc wins on deployment weight and speed, which matters at volume.
• React charts. Boring answer: Recharts, and it is the right default for most dashboards. Semiotic when you need networks, Sankeys or streaming — nothing else on the shortlist does those.
• Generative image pipelines. ComfyUI is genuinely the mature option here — three years old, commercially backed, production-grade. Its risk is the licence, not the code. For a simple embedded pipeline, diffusers under Apache-2.0 avoids that question entirely.
• Agent orchestration. Boring answer: your agent's built-in subagents, then LangGraph when you need explicit, testable orchestration. Reach for Ruflo only after you have hit a real wall.
• Terminal multiplexing. tmux, until you are genuinely running several agents at once — then Herdr earns its place.
• Bulk find-and-replace. sd. Prebuilt binaries, regex, and one command to install — the boring answer that is also the correct one.
• Text measurement. Batch your DOM reads first — it is free. Pretext when there is no DOM at all, or when you have measured the thrash and it is real.
• iOS builds without a Mac. Expo EAS or Codemagic if budget allows. ios-builder when you want to own the pipeline and pay per minute.

Where new tools belong

None of this is an argument for only using ten-year-old software. Every mature project was new once, and several of the tools in this series solve problems the incumbents have simply never addressed. Adaptive selectors are a genuinely new idea. Nothing mature does them.

The discipline is about placement, not avoidance:

• Internal tooling — adopt freely. If it breaks, you lose an afternoon.
• Build-time dependencies — adopt carefully. A broken build is loud and recoverable.
• Runtime dependencies in client software — adopt slowly, behind an interface you control, with a named fallback.
• Anything touching client data or credentials — maturity and provenance are non-negotiable.

And write down the exit. "If this is abandoned we move to X, and it costs about a week" is a complete answer. Not having one means you did not evaluate the tool, you just liked it.

Conclusion

The most useful habit is small: when you see a big number, look for the small ones. Version. Last release. Open issues. Contributors. Licence. They take five minutes and they are the difference between a tool you chose and a tool that happened to you.

Everything in this series is worth knowing about. Roughly half of it is worth putting on a client's critical path today. The checklist above is how you tell which half.

Want a second opinion on your stack?

DI Solutions reviews technology choices before they become commitments — licences, maintenance risk, migration cost and what the realistic exit looks like. Talk to our engineering team before the dependency list is frozen.

Reference links

• Choose a License — plain-English licence comparison
• Open Source Initiative — approved licences
• Semantic Versioning — what a 0.x version is telling you