Four stars, no licence — and I was wrong
A project with four stars, built in a day, untouched since. My assessment stood in bold in my notes. Four days later I had to retract it.
I wanted a live view of my Blink cameras in Home Assistant. The bundled integration provides none — it reports for all ten devices that no stream is available.
There is a community project that solves exactly that:
Teethree89/ha-blink-live-view-proxy.
It speaks Blink’s own protocol — the same one the app uses — and fetches a real
live view instead of assembling freshness out of old clips.
I assessed it before using it, and the assessment stood in bold at the top of my documentation.
It was wrong. Not slightly off, but measured against the wrong yardstick. This is the first of three parts about a project that taught me more about my own judgement than about cameras.
What I wrote down on 29 August
| Stars / forks | 4 / 4 |
| created | 26.05.2026 |
| last push | 27.05.2026 |
| licence | none |
| open issues | 3 |
And my sentence: “The project came into existence in one day and has been untouched since.”
Noted as an open item: “Check back in a few weeks whether the project is still alive.”
That sounded sober and was not. The table was headed “What the project is worth”, and right at the top, in bold, stood the star count.
What it looked like four days later
| 29.08. | 02.09. | |
|---|---|---|
| Stars / forks | 4 / 4 | 6 / 6 |
| last push | 27.05.2026 | 01.09.2026 |
| licence | none | MIT |
In three days: three released versions, automated build checks set up, a roadmap written, two external contributions merged. On a single day, nine commits.
The star count stood first, in bold, under the heading “What the project is worth”. It predicted nothing.
And that cuts both ways: six stars say as little about this project as four did.
What would actually have said something
It was in the same table, one row down, outshone by the star count: three open issues.
Their number was not the point, their content was. Two of them stopped every new user at the first step. The login failed in the version I tested — more on that in the second part.
That is an entirely different finding from the one I noted:
Not “nobody is interested”, but “nobody gets in”.
A project nobody can get into looks, from outside, exactly like an abandoned one. From inside it is the opposite: somebody there is waiting for somebody to say where it sticks.
The one item with real weight
Of everything in my table, exactly one row was sound: the missing licence.
Without a licence, nothing says what you may do with the code. That is not a feeling and not an extrapolation from a number, it is a gap anyone can see. Running a project without a licence in your house means not knowing where you stand — even if nobody minds.
Since 1 September there is an MIT licence in the repository. That formally settles what was previously only practice.
That is the yardstick I should have been looking for: not how many people once clicked a star, but whether the foundations are in order — licence, a reachable maintainer, traceable issue reports.
What I still see critically
So that this does not swing from too negative to too positive — three points are unchanged and were stated from the start:
It holds the whole account. Not a device key, but the credentials for every camera in both houses. Anybody deploying this should know what sits there.
Despite the name it is not local. The live view still runs through Amazon’s cloud; the project only translates. What you gain is a viewer in your own dashboard, not independence from Blink.
The battery cost appears nowhere. Live view is the most expensive thing a battery camera does, and the Blink app warns about it explicitly. The project’s README says nothing. What defused it here was a decision that has nothing to do with software: the doorbells are on mains power. That is exactly where the benefit is greatest — it rings, and you want to see now who is standing there.
For the four outdoor battery cameras the reservation stands. There a live view only runs if somebody opens it by hand, and anybody who does that habitually is trading runtime for convenience.
So what?
I inferred a project’s liveliness from a snapshot. That is the same methodological error I made with the cameras themselves, with the network measurements, and with the cooling model: see a number, invent the interpretation, and fail to ask the obvious control question.
Here the control question would have been: why is nobody contributing?
Five things I now look at first in open source projects:
- Is there a licence? The only item that needs no interpretation.
- What is in the open issues? Two issues blocking every entry mean something entirely different from twenty feature requests.
- Does anybody answer? Not “when was the last push”, but: does a bug report get a reply?
- What does it hold of my credentials? A device key is not the same as a whole account.
- What does the README leave out? Here it was the battery cost — the property you notice after three weeks of operation.
The star count is on none of those lists. It measures how many people once found a project interesting — not whether it holds.
The second part is about why nobody got in. The answer was a three-digit number nobody checked for.
If you want to follow this: use RSS
No newsletter. You give me no address, I keep no list, and nobody has to agree to anything to learn that an article is finished. RSS is the older and, for both sides, the more honest solution.
How it works, and why no newsletter
- 1Get a feed reader. No account needed with an app on your phone or a browser extension; use a hosted service if you prefer.
- 2Add the address above to it.
- 3Done. New articles turn up in your reader by themselves — unread stays unread, and nothing lands between invoices and ads in your inbox.
Why that is better: your reader fetches the file. I get no address and cannot see who reads or whether anyone opened it. Unsubscribing means deleting the entry — no link, no confirmation mail, no me.