devfreebooks: a catalogue of free developer books that is really a folder of JSON

The repository is the website and the data is JSON

DevFreeBooks is the repository of the site at devfreebooks.github.io, and its stated purpose is to collect ebook links. The description calls it a huge collection of free books for developers.

What makes it interesting is that the content is not stored in a database. The site reads JSON, one file per category, and the repository listing shows the public/ directory that holds them alongside a small set of build scripts. The primary language recorded for the project is CSS, which is a reminder of what the site actually is: a static front end with a build step, not an application.

The one hard rule for contributors is stated in bold before anything else. All books you add must be freeware and for web developers. That is the whole editorial policy, and it is deliberately narrow, which means the catalogue is a list of links rather than a library.

Each entry in a category carries a title, a description, an author or publisher, a page count, a publication year, a language, a download URL and the date the entry was added. The category itself carries a name, a subtitle, a list of tags, a description, a link to the official site and an image.

So the data model is small and legible, and a person can read the entire catalogue as text. For a project whose purpose is to be read rather than to be queried, that is exactly the right shape.

Two ways to add a book, and one of them needs no git

The readme gives two submission routes, and the split between them is the useful part.

The first is a Google Docs form. You submit the book through the form and the maintainers take it from there, which means contributing a link does not require a GitHub account, a fork or a pull request, and the person who maintains the catalogue decides what to do with the submission.

The second is a pull request. You fork the repository, edit the category file for the category you want to add to, and send the change. The readme is explicit that you need to fork first, and then it points you at the file to edit, which is in a folder of category files under the public directory.

"index": {
  "name": "category-name",
  "subtitle": "Category's name",
  "tags": ["category's tags"], // "used in the filters: 'framework', 'language', 'conceptual', 'frontend', 'mobile'"
  "about": "Category's description",
  "site": "url of the official category site",
  "image": "category-image.jpg", // Category image is required

Two things stand out in that schema. The tag vocabulary is enumerated in a comment, and it is short, five values covering frameworks, languages, conceptual topics, the frontend and mobile, which means the filters on the site are built from a fixed set rather than from free text. And the image is marked as required at the category level, with a note that the image file has to be a jpeg or jpg at 350 by 195 pixels.

The readme also records the fallback: if you do not add an image attribute for a book, the default category image replaces it. So a missing per-book image is not an error, it is a cosmetic substitution, and a contributor who wants a thumbnail has to add one themselves.

What a real category file looks like

The readme includes a complete example rather than a fragment, and it is the fastest way to understand the shape of the data.

The example is the Node.js category. It has a name, a subtitle, a tag list of language and framework, a description that explains what Node.js is in terms of its event-driven, non-blocking I/O model, a link to the official site, and an image file name. Then it has one book.

The book entry is a concrete record: a title, a description of what the reader will learn, an author name, a page count, a publication year, a language code, the date the entry was added, and a URL pointing at the publisher's page for the ebook rather than at a file. That last detail matters. The catalogue links to where the book can be obtained, and the freeware rule is enforced by the submission process rather than by hosting anything itself.

So a category file is the unit of curation, and the categories are grouped by the tags the site filters on. A contributor adding to the Node.js category edits that one file, and the change is a diff of a few lines, which is what makes the pull request route workable for people who have never opened a repository before.

The consequence for anyone who wants to reuse the data is that the entire catalogue is a set of JSON files that can be read, filtered or imported into something else without touching the site at all.

The build is Grunt and harp, and the feed is generated

The package file describes the build as a set of four scripts, and they explain the shape of the project.

Starting the site in development mode cleans the previous output, runs a Grunt prebuild step and then serves the directory with harp on port 3000, which is the address the readme tells you to open. The build script does the same thing in the other direction, prebuilding for production, serving into a directory that becomes the site root, running the production Grunt task and cleaning up afterwards. The deploy script builds and then runs a Grunt deploy task, which is where the GitHub Pages plugin comes in. And the clean script is a separate node script that removes the leftovers.

The dependency list makes the toolchain concrete. Grunt is the task runner, with plugins for cleaning, compressing, image minimisation, environment variables, newer-than checks and shelling out. The pages plugin is the deployment mechanism. The server is harp, and the version pinned is 0.41.0, which dates the project. Two dependencies are for the content side rather than the build: a moment library for dates and an RSS library, which is what the feed script at the repository root is for.

So a category file is not just data for a page. It is also the input to a generated feed, which is how a static site of this kind stays discoverable.

The development instructions are the standard ones. You need the latest Node.js, you clone the repository, install with npm or yarn, and start the server.

The site is static, the branches are not obvious, and the licence has a wrinkle

A few details are worth knowing before you open a pull request.

The default branch is named dev, which is not what you would guess for a project whose repository name ends in the pages domain, and it tells you the site is built from a development branch and published from somewhere else by the Grunt deployment task.

The licence is where the readme and the repository listing disagree. The listing records the licence as unknown, while the readme states MIT and links to a licence page hosted under the author's own name rather than a file in the repository. The package file, meanwhile, declares the MIT licence in its metadata. For a data project where the content is contributed by many people, that is worth resolving explicitly rather than assuming, and the right place to ask is the form or the issue tracker rather than a pull request.

The funding model is donations, both a Bitcoin address and a PayPal link, with the readme asking for help to keep the project running free for everybody. There is no advertising and no affiliate link in the data model, which is consistent with a catalogue that links to publisher pages for books that are described as freeware.

Finally, the scale of the thing is not documented anywhere in the readme, and the maintenance signal is thin: the last push was on 2026-09-14, the package version is 3.0.0, and the repository publishes no releases. So if you are planning to rely on this list as a maintained resource, the honest answer is that it is a well-organised snapshot rather than a project with a visible update cadence.

Editorial conclusion

Adopt DevFreeBooks if you want a link list of free programming books that you can host yourself, query and extend, because the content is plain JSON in version control and the site is static. Do not adopt it if you need a curated catalogue with editorial standards, because there is no stated selection policy beyond the rule that the books must be freeware and aimed at web developers. Before you add to it, read the category file schema carefully, because the image rule is strict and a missing image attribute silently falls back to the category default, and check the licence file yourself, since the repository listing records the licence as unknown while the readme states MIT under a separate licence page.

Frequently asked questions

Official sources

1. devfreebooks/devfreebooks.github.io on GitHub
2. Issues
3. Project website
4. README