php-youtubers and the odd case of a directory maintained as a script

The deliverable is a README and nothing else

The repository description is a curated list of PHP YouTubers, and the top level of the repository contains four entries: a .github directory, the README.md, a script_errors.log and an update.php file.

That is the whole project. There is no package on Packagist, no documentation site, no changelog and no release history, since the repository has no GitHub releases. The primary language recorded for the repository is PHP, which comes entirely from the update script.

What the README is, in practice, is a data file formatted for humans. Each line follows the same pattern: a bolded channel name that links to the YouTube channel, then a subscriber count, then the person's name, then their role. A few entries in the middle of the list are marked only as Content Creator, with no name and no affiliation, which suggests the data is filled in where it could be and left blank where it could not be.

The formatting is a deliberate choice rather than a table, because a table would have needed a header row and a consistent column layout, and the list instead uses a flat structure that keeps each channel on one line. For a README, that reads well. For a machine, it is a parsing job, and that is what update.php is for.

The list is ordered by audience, not by topic

The entries are sorted by subscriber count, descending, from about 499K at the top down to about 3.5K at the bottom. Nothing in the file states that this is the sort key, but the ordering is consistent across every line, and it makes the file's value obvious: the first entries are the channels with the largest reach, and the tail is a long tail of small, focused channels.

The spread is roughly a hundred to one, which tells you something about what a newcomer should expect. A person picking a channel to follow has a large gap between the well known names and the small ones, and the small ones are where the more specific content tends to live.

Two channels are attributed to the same person, Povilas Korop, who appears as the founder of Laravel Daily and again under the name Filament Daily, and the directory treats them as two channels with two audiences. Channel names that are not handles, such as EspecializatiBr, zaprogramujzycie and mateusguimaraes, appear with a plain name link, while the rest use the @handle form, so the file mixes two link shapes without a comment explaining the difference.

Laravel and PHP framework channels fill the top of the list

The upper half of the directory is heavily weighted towards one ecosystem. The second entry in the file is the Codecourse channel at about 340K subscribers, run by Alex Garrett-Smith, and the description records him as the founder of Codecourse. Laravel Daily appears at about 154K with Povilas Korop, Laracasts at about 81.6K, the official Laravel channel at about 66.1K, Laravel News at about 28K with Eric Barnes, Laravel Jutsu at about 26.7K with Ludovic Guenet, Laravel Con EU at about 32.9K, and a channel for Laravel Daily's Filament product at about 10.9K.

Several of the largest entries are people rather than companies. The top entry in the file is Dani Krossing at about 499K, described as an independent developer, and Grafikart with Jonathan Boyer at about 321K sits third. Adam Wathan, recorded as co-founder of Tailwind CSS, is at about 37.7K, and Nuno Maduro at about 17.8K is listed as a developer at Laravel, with Josh Cirre at about 16K as support engineer and developer relations at Laravel.

What the list does not do is filter by language. PHP named people such as Carlos Buenosvinos, recorded as the author of Domain-Driven Design in PHP and CQRS by Example, sit in the same file and in the same order as framework channels, and several entries with a Laravel connection are described in terms of their company rather than their PHP work. The curation criterion appears to be the PHP ecosystem rather than the PHP language, which is a broader and more useful thing to be, and also a vaguer one.

update.php and script_errors.log are the interesting files

The two non-README files are the ones that reveal how the directory is actually kept current, and neither of them is documented in the README. A README that lists subscriber counts has to refresh those counts, because a stale subscriber count is the kind of detail that quietly misleads. The presence of an update script and a separate log of script errors tells you that the refresh is automated rather than manual.

The log file name is the informative part. A file called script_errors.log is a record of failures, which means the script that generates the list also fails sometimes, and the failures are captured rather than swallowed. That is a sensible pattern for a scheduled job that scrapes third party data, and it also implies that the README may lag behind reality whenever the log has entries.

Neither file is documented: the README does not say how often the script runs, what it considers a channel, how it derives the subscriber figure, or what it does with the role descriptions. There is no CONTRIBUTING guide here either, unlike most of the projects in this queue, so the rules for adding a channel are not written down anywhere in the repository.

The .github directory is present, so some automation exists around the repository itself, but with no workflow file quoted in the documentation, the details of how the script is scheduled are not something you can confirm from what is documented.

Reading the list well, and what a maintainer should watch

The honest way to use this directory is as a starting point rather than a source of truth. A subscriber count is a snapshot, and a channel can change direction, stop publishing or be renamed without the file being wrong at the moment it was written.

Two things are worth watching if you maintain it. The first is the role descriptions, which are written in a fixed vocabulary: independent developer, founder, developer at, content creator, and a few longer forms such as educator and web programmer, and founder of a named product. That vocabulary is what makes the file scannable, and it is also what will drift, since a channel owner changes job. The second is the empty entries. Several lines carry only a Content Creator description, which is a placeholder that has been left in place rather than a data point.

The list also has a geographic spread that is worth noticing, because it tells you where the videos are produced from. The names in the file come from many countries, and the channel names include Portuguese and Spanish language channels, which suggests the directory is not limited to English language PHP content even though the entries are described in English.

For a reader, the practical use is simple and immediate: open the README, and you have a ranked list of channels with an idea of what each creator does. That is a genuine convenience, and it costs a single page load.

Where a link list is the wrong tool

The first wrong case is anything programmatic. There is no documented API, no feed and no export format, so if you want channel metadata in your own tooling you would be scraping a Markdown file and reimplementing the parsing that update.php already does. For a directory this small, the list is best read by a person.

The second wrong case is expecting a ranking to mean quality. The ordering is by subscriber count, which measures reach and nothing else. A channel with a large audience may publish rarely, and a smaller channel may be the one that actually covers the problem you have. The file gives you a way to find channels, not a way to judge them.

The third is the licensing question, which is genuinely unresolved here. The repository records no recognisable licence, and there is no LICENSE file at the top level. The content of the README is a list of names, channel links and job titles, and job titles are facts about people, so publishing a fork that presents the same directory under a different banner is a different question from copying an application. Whichever side of that line you are on, the absence of a licence file means nothing is granted by default, and the repository owner is the person to ask.

The alternative worth naming is simply searching YouTube yourself and subscribing to what fits, which gives you the same channels with none of the staleness, at the cost of doing the work each time. The value of a curated directory is that someone else did the sorting once. That value decays with time, and with a script that logs its own errors, it is worth checking how fresh the numbers actually are before you treat the order as meaningful.

Editorial conclusion

php-youtubers fits a PHP developer who wants a single page to find a channel worth subscribing to, and it costs nothing to read since the whole directory is one README. It is not usable as a feed, an API or a ranking source, because the repository documents no interface beyond the file itself. Before you rely on it, open the README and check the error log next to it, since a directory maintained by a script can quietly keep a channel after it stops publishing, and confirm the licensing position yourself because the repository records no recognisable licence.

Frequently asked questions

Official sources

1. Issues
2. php-youtubers/directory on GitHub
3. README