Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

Introduction — what actually happened while writing this series
What a star count says and what it does not say
How to count maintenance signals yourself
Licences must never be guessed at from common sense
A checklist before production adoption
Finally — numbers are point-in-time values
Links

Introduction — what actually happened while writing this series

While writing the previous five posts, I checked 59 repositories directly on GitHub. Along the way I came to think that what I learned might be more useful than the lists themselves.

The clearest lesson is this. A good share of what I thought I knew was wrong. Repositories had been moved to different accounts, licences differed from what I remembered, and a project I assumed was busy had its most recent push three months earlier. If I had not checked, I would have written all of it exactly as I remembered it.

What a star count says and what it does not say

Stars tell you only that someone paid attention at some point in the past. They are almost never taken back, so in practice they accumulate in one direction only. The number does not fall when a project is left unattended.

Take a concrete example from the series. open-telemetry/opentelemetry-collector had 7,377 stars, among the lowest in the part 4 list. Yet this component sits right in the middle of the observability pipeline at a great many organizations. The project simply splits its work across several repositories, so attention is spread thin.

In the other direction, browser-use/browser-use is a repository created in October 2024 that has reached 108,900 stars. That is a big number, but the number does not guarantee interface stability.

Stars are not a ruler for scale, they are a ruler for buzz.

How to count maintenance signals yourself

Start with what you can check numerically. The commands below work without authentication, but the hourly request limit is low, so if you plan to look at several repositories it is better to attach a token.

# Example: check basic information and recent release cadence in one go
OWNER_REPO="ossf/scorecard"
curl -s "https://api.github.com/repos/${OWNER_REPO}" \
  | jq '{full_name, license: .license.spdx_id, stars: .stargazers_count, pushed_at, archived}'
curl -s "https://api.github.com/repos/${OWNER_REPO}/releases?per_page=5" \
  | jq -r '.[] | "\(.published_at[0:10])  \(.tag_name)"'

Here is what to look at.

Most recent commit date: whether it is measured in days or in months. In part 5, bentoml/BentoML had a most recent push of 2026-08-03 at the time of checking, and in part 1, Aider-AI/aider was 2026-05-22. Neither means the project is dead. It means there is more to look at.
Release intervals: whether the dates are regular, and how long it has been since the last release. If there are commits but no release for a long stretch, it can mean the flow that reaches users is blocked.
The archived field: if it is true, the repository is in a frozen state.
Issue response: whether maintainers react within a few days to recently opened issues. Look at whether there is a response, not at the count.
Contributor distribution: more important than the number of contributors is the number of people who actually carried out recent merges. Even with thousands of contributors, if merge rights are concentrated in two people, the bus factor is 2.

The last item is the hardest to automate and the most important. This blog covers it in more detail in the post on the bus factor.

ossf/scorecard (Apache-2.0, 5,628 stars, most recent push 2026-08-10, as of 2026-08-12) automates a good many of these checks. That said, rather than using the score straight as a pass mark, it works better as a tool for reading which items lost points.

Licences must never be guessed at from common sense

This was the biggest surprise in the series. For 6 of the 59, GitHub could not classify the licence automatically, and opening the LICENSE files directly showed contents that varied from one to the next.

open-webui/open-webui takes a BSD 3-Clause shape and adds a clause prohibiting removal of the branding. Because there is a usage restriction, it is not open source as OSI defines it.
The LICENSE for oven-sh/bun explains both that Bun itself is MIT and that it statically links an LGPL-2 library, together with the conditions that follow from that.
zed-industries/zed keeps LICENSE-GPL and LICENSE-APACHE side by side.
BerriAI/litellm and SigNoz/signoz declare that specific directories follow a separate licence.
pgvector/pgvector carries the permissive licence wording of the Postgres family.

To put it together: the licence shown in the GitHub sidebar is a summary, not the original text. And the fact that you can see the source does not mean it is open source. Distinguish between the case of something like AGPL, where the conditions are strong but it is still an OSI-approved open source licence, and the case where a usage restriction is attached and it is not open source at all.

Check the full licence text yourself, and route commercial adoption through legal review. This post is not legal advice.

A checklist before production adoption

Once the technical review is done, and before you decide to adopt, I recommend putting the following down in writing.

Have you recorded the exact owner/repo path? Are you referring to a repository with a similar name, or to an old path?
Have you read the original text of the LICENSE file? Of internal use, redistribution, and providing a service, which one does your use fall under?
Have you checked recent commits, recent releases, and issue response yourself?
How many people hold merge rights? What happens if those people leave?
What does the project say about itself? Does it state that it is pre-1.0 or experimental?
Is the capability you plan to depend on inside the open source repository, or only in the commercial product?
What is the exit cost? Can you get your data out in a standard format?
When a vulnerability is disclosed, who finds out, and when?

If there is even one of the eight you cannot answer, that is the next item to check.

Finally — numbers are point-in-time values

This is why every figure in this series carries a date. Star counts and recent activity keep changing. A number without a date cannot be verified, and a number that cannot be verified does not work as evidence.

By the time you read this, the numbers will already be different. That is why the procedure for checking outlasts the list.

Repository details (stars, licence, recent activity) were checked directly on GitHub on 2026-08-12 and are point-in-time values. The numbers and the status change.

Links

Series: Previous post — Data and ML pipelines · First post in the series — AI agents and LLM tooling