An About section that includes “Projects” is answering a motive question: why did this site build tools at all? Not which file each helper reads—that is a map. Not how the menu was nested—that is information architecture. At /aboutus.projects the historical Cumulus host kept the narrative: a community software outpost wrote PHP because Cumulus files did not, by themselves, make a complete public website.
This article is that narrative. It is distinct from the research map of Cumulus-side projects, which indexes engineering problems (graphs, logs, banners, checks). It is also distinct from the About-tree listing. Modern TNET Weather does not maintain the historical PHP, does not ship Cumulus, and does not claim the original workshop’s authorship.
Historical context
Cumulus, as documented on the Cumulus Wiki Software page, reads a personal weather station, keeps logs, and can process web tags into pages it then uploads (last checked 13 August 2026). That is a complete logger-to-file system. It is not a complete answer to every public-web job operators actually had.
Operators still wanted a live banner a forum could hot-link, a 24-hour trace, a WAP deck, a heartbeat that distinguished still air from a dead FTP login, extra includes, and a place to declare cookies. Vendor software did not have to supply those. Community PHP did. The Wiki catalog of TNET Cumulus Scripts is evidence that this hostname was cited as one workshop that named such helpers (last checked 13 August 2026).
The About-section “projects” page was the prose explanation a visitor saw when they clicked Projects under About Us: why the workshop existed, who it was for, and what kind of thing a “project” was. The original page is not rehosted. Named packages stay offline for license reasons. The motive can be written without the ZIP files.
Why the tools were built
Four pressures produced the workshop. They are still the right pressures to name on an About page.
The file is not the view. realtime.txt is one line. A visitor wanted a page, a PNG, or a tiny deck. Someone had to derive a view from an observed packet without pretending the PNG was a second thermometer. Tools existed to make that derivation explicit and repeatable.
The current line is not a series. A graph of the last 24 hours needs an archive of snapshots. Cumulus logs and the dayfile are vendor climate products. A homemade high-frequency log is a derived series. Operators built accumulators and plot packs because the public wanted a figure, and a figure without a series is a lie or a cartoon.
The upload can die while the page still looks live. A heartbeat project is not a product feature. It is the motive “do not let stale files impersonate weather.” That motive belongs in an About narrative because it is why a software outpost bothered with unglamorous checkers.
Citation needs names. A forum answer that says “use the graph pack” is useless in five years unless the pack has a public name and a host. Projects were named so the Wiki, Raspberry Pi threads, and other operators could point at an object. The outpost identity article is about that host. This page is about the decision to treat helpers as named works rather than as anonymous footer scripts.
None of these motives is “become a forecast office.” Software forecast tokens in a Cumulus packet remain scenario output from the station program. Warnings come from the National Weather Service or the relevant national service.
Who the tools were for
The audience was operators and citers, not a mass consumer weather brand.
- people running Cumulus who needed a helper that understood Cumulus files, not Weather Display ClientRaw;
- wiki editors who needed a URL that meant a graph pack or a parser;
- neighboring stations that hot-linked a banner and owed a credit;
- the operator of this host, who needed the same jobs for their own public pages.
That audience is why Projects sat under About as well as under a /projects tree. About explains the workshop to a human who asked “what is this site?” The map explains the workshop to a human who asked “which problem am I in?” Both questions are legitimate. They are not the same question.
Credits for people and packages belong on membership and website-info pages. The narrative here should not turn into a name list.
What “project” meant in this About section
In this narrative, a project is a bounded engineering job with a public name: input file, output artifact, and a known failure mode. It is not a marketing campaign, not a grant, and not a claim of affiliation with Sandaysoft or with MX maintainers (MX on GitHub; last checked 13 August 2026).
A project is also not automatically redistributable from this hostname. Acquisition of a domain does not transfer copyright. Where a living upstream still offers a named script under its own notice, that upstream is the download story. This About page is the motive story.
Keep evidence labels in the narrative, even though this is not the map:
- packet and logger values are observed (plus software-derived extremes the program already computed);
- homemade logs and images are derived;
- dayfile rows are historical daily appendices;
- Zambretti-style phrases are scenario text.
An About narrative that calls every PNG “live weather” is how derived views contaminate citations.
Distinct from the map and from the slash listing
/projects on this host is the research map: problem, file contract, child URL. Use it when you already know you are in graphs, logs, or checks.
/aboutus.projects is the motive essay: why a Cumulus About section talked about building tools.
/aboutus/projects is the About-tree listing path (slash IA). It should remain a different job—how projects were grouped under About—so this dotted URL does not steal that listing. If you came from an old menu labeled Projects under About Us, you wanted the story first; follow the map when you need the catalog.
Do not flatten the three into one generic “we had scripts” page. The backlink graph treated them as different objects.
Practical reading
- Start here for motive, then open the map for the job you actually have.
- Do not install from this article. There are no packages on this page.
- Name derived views as derived when you cite historical figures.
- Follow current official docs for software you still run (Wiki Software; MX GitHub; last checked 13 August 2026).
- Keep About, map, and listing URLs separate in your own notes so citations stay precise.
Modern relevance
Operators still write glue: a Pi job that appends JSON, a dashboard card, a stale-file check. The motive has not changed. Files are not views; current lines are not series; silence is not calm weather; named works are citable. MX’s HTTP interfaces reduce FTP, not the need for that discipline.
TNET’s preservation job on this path is the narrative, not a support desk and not a ZIP mirror.
TNET research bridge
Explaining why a derived view exists—and refusing to treat it as a native observation—is the same habit TNET states for public evidence on how the service works. That page is the modern service, not a Cumulus project list. The Cumulus legacy hub collects related historical pages.
Sources
- Cumulus Wiki: Software (last checked 13 August 2026)
- Cumulus Wiki: TNET Cumulus Scripts (last checked 13 August 2026)
- Cumulus MX on GitHub (last checked 13 August 2026)
- National Weather Service