Open Apps
The list had an audience. The product needed a maintenance model.
Turned a long-running repository of complete open-source applications into structured, reviewable developer infrastructure without pretending the 2026 rebuild earned its history from zero.
- Role
- Creator and maintainer
- Period
- 2017–Present
- Status
- Public
- Ownership
- Created and maintained
Overview
My fastest learning rarely came from a tutorial. It came from finding a complete application, getting it to run, and tracing one real behavior through its database, API, UI, errors, and deployment assumptions.
The difficult part was often finding the application. GitHub search mixed production systems with libraries, templates, abandoned demos, and repositories whose screenshots promised more than the code delivered.
In 2017, I started collecting useful full applications. In 2026, that long-running list became Open Apps: a structured directory for developers who want to study working systems or find a project worth contributing to.
My role
I created and maintain the repository, current Astro product, record model, curation criteria, validation workflow, contribution path, and publishing direction.
The repository began years before the current site. Its audience and history belong to the lineage, not solely to the 2026 rebuild.
01
The old list proved demand and created debt
At the 2026-07-21 snapshot, the repository had 4,334 stars and 788 forks. The current dataset described about 79 curated applications.
The star count is meaningful: developers repeatedly wanted a way to discover complete application code. It also carries the history of the original list. Saying “the new directory earned 4.3k stars” would be false; saying the history does not matter would be equally false.
The old format produced its own maintenance problems:
- entries used inconsistent names and descriptions;
- categories drifted as the list grew;
- links and repository status changed;
- screenshots and README claims could outlive the application;
- contributors could add a row without understanding the inclusion standard;
- every new output required another hand-maintained representation.
A successful list had become a dataset without a data model.
02 · Decision record
The product decision
The rebuild moved each application into a structured record with stable identity, source links, categories, technology metadata, editorial description, and validation rules.
From that source, the project could generate the website, detail pages, search/filter data, sitemaps, and machine-readable outputs. A contribution became a reviewable record change instead of careful Markdown formatting.
This was less glamorous than redesigning the cards. It addressed the actual bottleneck: the directory could not remain trustworthy if every output and freshness check depended on one maintainer remembering every convention.
03
Curation stayed human
Repository metadata can be refreshed automatically. Inclusion cannot be delegated entirely to an API.
Open Apps asks questions GitHub metadata does not answer:
- Is this a complete application or a framework demo?
- Can a developer follow a meaningful product behavior through the code?
- Is the repository active enough to study without becoming archaeology?
- Does the description explain what exists rather than repeat marketing copy?
- Is there a useful contribution path?
Automation proposes, validates, and refreshes evidence. Editorial review decides whether the record belongs. The unresolved challenge is making that judgment scalable without allowing low-signal submissions or turning me into the permanent bottleneck.
04 · System view
Architecture
The current flow is intentionally file-first:
discover a candidate
→ normalize it into a typed record
→ validate required fields and taxonomy
→ enrich repository evidence
→ review the editorial decision
→ generate public and machine-readable outputs
→ return stale or broken records to a maintenance queueGit history preserves why a record changed. Static output keeps the public product fast and inexpensive. The repository remains portable instead of hiding the dataset inside a private CMS.
05
The repeated pain became Grove
Once Open Apps had schemas, importers, validation, taxonomy, review state, generated indexes, and release workflows, another decision appeared: which parts were product-specific and which parts represented a reusable maintenance lifecycle?
That question produced Grove.
The sequence matters. I did not begin with a universal community-knowledge framework and search for a demo. I began with a real directory, let maintenance pain repeat, and then extracted the boundary.
06 · Outcome
Result
Open Apps is live and publicly inspectable. It combines a repository with durable historical reach and a current product model that can be validated, reviewed, and generated instead of manually synchronized.
What remains unproven is equally specific: repeat visitor behavior, search-to-repository clicks, useful submissions, acceptance rate, contributor retention, and how much maintenance the new workflow actually removes.
Stars prove durable attention to the problem. They do not prove every new product decision.
07 · Reflection
What I learned
An inherited audience is not a footnote to hide. It is an asset whose origin must stay visible.
The metric I care about next is not another thousand stars. It is whether a developer repeatedly finds a real system worth studying, running, or contributing to—and whether the directory can improve without depending entirely on my memory.
Links
Next case study
Fleetbase