Our editorial standards
Editorial policy
Clear facts. Useful context.
A history you can explore.
Monolith documents influential desktop software and its place in computing history. These standards guide how we select entries, use evidence, explain significance and improve the archive when new information becomes available.
Selection & scope
Why a product belongs in the archive.
Selection considers historical importance, practical influence, longevity, adoption and the communities around a product. A program may deserve attention because it introduced an enduring idea, changed a creative workflow or served a particular group of users especially well.
The catalogue includes established names and less familiar applications across different platforms and eras. Inclusion is an editorial judgement about a product’s contribution, rather than a numerical measure of its quality. The archive is selective and continues to develop; an absent product is not a judgement about its value.
Featured profiles and directory placement help readers discover entries. They do not establish a universal ranking or identify the best software for every task.
Research & evidence
Start with the record. Explain the context.
Documented facts and editorial interpretation serve different purposes. Profiles should make that distinction clear and give readers a route to the supporting material.
Prefer original records
Release notes, product documentation, project histories, developer announcements and archived official pages provide a starting point for dates, features and development milestones. Product claims should be understood in their original context.
Add independent context
Contemporary reporting, reputable archives and well-supported historical accounts help explain adoption and influence. Claims such as “first”, “largest” or “industry standard” need specific evidence and a clear scope.
Make references useful
Sources appear at the end of a profile where available. A reference may support one part of an entry rather than every statement. Source checking dates, when recorded, describe that reference and are separate from the entry’s editorial review status.
Accuracy & review
Read the details in their time.
A first release, an earlier project and a later rebrand can each have a different date. Profiles should distinguish those events rather than presenting a product family’s entire history as a single launch.
Features, supported platforms and licensing can change between versions or editions. Descriptions should identify the relevant period where it matters. A product’s lifecycle status describes its development or availability; its editorial review status describes the catalogue record.
Where evidence is missing or conflicting, the aim is to preserve that uncertainty rather than invent precision. Historical significance is an interpretation of the available record and should explain the reasons for that interpretation.
Review labels help readers understand an entry’s editorial stage. They should be read alongside its references and version context: software and source material can change after a review.
Perspective & independence
Keep editorial decisions clear.
Advertising and editorial coverage
Advertising is separate from the archive’s selection and interpretation of software history. An advertising enquiry does not secure inclusion, a favourable description or a particular editorial position.
Read about advertisingContext before scores
Comparison pages bring catalogue details together without assigning performance scores. Differences in purpose, era, platform and edition matter when interpreting features. A historical profile is an introduction to a product, rather than a benchmark of every current release.
Explore software comparisonsCorrections & contributions
Help make the record more accurate.
Use Report an error at the foot of a software profile to identify the entry automatically, or send a source suggestion through our contact page. A useful report includes:
- The product name and profile URL.
- The specific detail to change and your suggested correction.
- A supporting source, with the relevant date, version or passage where possible.
Corrections are assessed against the available evidence. A change may clarify a date, update a reference or revise an interpretation. Additional context is welcome even when an entry is already marked Reviewed.
Learn more about Monolith or explore the software archive.