Every entry in engineering-blogs is a name and a URL, and the last push was 2024-08-21

Each row is a name and a bare address with nothing to judge it by

The unit of entry is a line of the form company name followed by a URL. 8th Light, AdRoll, Airbnb, Algolia, Asana, and AWS appear that way, with no description, no author, no post count, no topic tag, and no indication of how often the publication writes. There is no score attached to inclusion either, so a name is either on the list or not, and the file records nothing about why. The consequence for a reader is that the list can tell you where engineering writing exists but not what is in it, so it cannot answer a question like how one company handled one specific problem. It is a set of front doors. You still have to walk through each one, judge the archive yourself, and decide whether to subscribe, and the only narrowing the file offers is the company name itself.

Three alphabetical tables and no index by subject

Navigation is three jump tables, one per section of the file: Companies, Individuals/Group Contributors, and Products/Technologies. Each table has a number row and then a full A to Z row of anchor links, which is a fast way to reach a name you already know. It is no help at all for a name you do not. There is no index by programming language, no index by framework, no index by problem domain, and no index by seniority, so the only lookup path offered is alphabetical by the name of the organisation or the product. If you want to see how anyone writes about consensus, stream processing, or on-call rotations, you have to guess which companies to open, and the jump tables will not help because the word you are thinking of does not appear anywhere in them.

GitHub Old sits directly beneath GitHub and nothing merges them

In the G section two adjacent entries name the same organisation: GitHub points at one engineering address, and the line below it is labelled GitHub Old and points at a different path on github.com. The file keeps both, with no note about which one is current, no redirect mentioned, and no removal date. It is the clearest evidence of how the list is maintained: new entries get appended, and entries that have been superseded stay exactly where they are, relabelled by whoever happened to notice rather than deleted. That choice does preserve some history, but it transfers work to the reader. A subscriber importing the feed list receives both addresses, someone scanning the table sees two rows and no guidance about the difference, and anyone maintaining their own reading list has to catch the duplication themselves. Nothing in the repository checks for it.

Eight company blogs in the first half live on Medium

Between 8th Light and the J companies, eight entries point at medium.com rather than at a domain the company controls: Airbnb, BBC, Criteo, eFounders, Expedia, Feedzai, Helpshift, and Housing.com. Several are publication-specific Medium properties rather than a redirect from a company site, which means the archive can stop without the company announcing it and without any domain changing. For whoever maintains the list there is nothing to repair, because the address was correct when it was written down. For a reader, a subscription built from this file inherits that dependency, and a dead entry is indistinguishable from a publication that simply went quiet. The entries that survive this are the ones on company-owned domains, so the habit worth forming is to open the address before adding it to a reader.

The OPML export comes from a Ruby script, so subscribing is all or nothing

The repository is more than a Markdown file. Alongside README.md there is generate_opml.rb, a Ruby script, and engineering_blogs.opml, the feed export it produces, plus a .ruby-version file, a Gemfile, and a Gemfile.lock. The useful consequence is that the whole list can be imported into a feed reader in one action rather than visited address by address. The limitation follows from how the export is produced. It is generated from the single Markdown source, so it carries every entry at once, and there is no per-company or per-section file you can import if you only want one feed. The export also inherits the file's own weaknesses, including entries that point at a company homepage instead of a post feed, and a reader will fail on those quietly rather than telling you which line failed.

No LICENSE file sits at the root of a list you are meant to copy

The top-level entries are .DS_Store, .github/, .gitignore, .ruby-version, Gemfile, Gemfile.lock, README.md, contributing.md, engineering_blogs.opml, and generate_opml.rb. There is no LICENSE file among them, and the repository metadata does not resolve to a licence identifier either, so no reuse terms are stated anywhere. Reading a public list and copying a line out of it is not the same act as republishing it, and the difference matters if you plan to do something larger with the content: fork it into a team wiki, mirror it, or turn it into an internal recommendation page. Without licence text you have permission by implication at best, and nobody will chase that for you later. The .DS_Store entry in the root is a smaller version of the same point: the file accumulates artefacts of how it was edited as well as its content.

The last push to master is dated 2024-08-21 and no entry carries a review date

The last push to the default branch master is dated 2024-08-21, and the repository publishes no GitHub releases, so there is no version to compare against and no release history to read. Nothing inside the file records when an individual entry was added or last checked, which means the list has no internal clock at all. An address that was correct in 2024 and one that has been dead for a year are indistinguishable in the table. That is the running cost of a plain list: the work of keeping it current happens outside the repository, in whoever notices a moved blog, and the file cannot tell you whether that is happening. If you plan to lean on this, check each address once by hand before subscribing, and treat a missing recent entry as normal rather than as evidence that a company has stopped publishing.

Editorial conclusion

Use this list as a starting set of names rather than as an index you can trust on its own. It groups entries by company, contributor, and product with jump tables that work well when you already have a company in mind, and the OPML export saves you from visiting every address by hand. It cannot answer a question about a subject, it records no date for any entry, it carries no stated licence, and the last push to master is dated 2024-08-21. Before you subscribe to anything from it, open each address, confirm the feed still resolves, and keep your own copy with the date you checked.

Frequently asked questions

Official sources

1. Official README
2. Project repository