OpenFiction didn't start as OpenFiction. It started as a feature that didn't fit inside another project.
It began with Book Assembly
Book Assembly is a book tracker - a place to log what you're reading, track your progress through books, and keep a record of your reading history. I built it as a side project because the existing options didn't quite do what I wanted.
You search online. The wiki article opens with their full biography, including the bit where they die in Book 7.
One of Book Assembly's core features is reading progress tracking. Not just "I'm reading this book" but "I'm on page 157 of this book." That granularity turned out to be more useful than I expected, particularly for longer series where you might put a book down for a few weeks and forget where you left off.
But the more I used it, the more I ran into the same problem every reader of long series faces: I'd want to look up a character, and the only options were fan wikis that assumed I'd finished the entire series. The moment I searched for a character mid-read, I was risking spoilers.
The problem with looking things up mid-read
This is a specific, concrete frustration. You're on Book 3 of a 10-book series. A character from Book 1 reappears and you can't remember who they are or what they did. You search online. The wiki article opens with their full biography, including the bit where they die in Book 7.
Spoiler banners don't help because you don't know what you don't know. The Coppermind's Time Machine - which lets you view a page as it existed before a book's release - is clever but requires you to know which book's spoilers you're avoiding and manually set it each visit. It's a workaround for a problem that shouldn't need one.
What you actually want is simple: show me what I know about this character so far, based on where I am in the series. Nothing more.
The feature that became a product
I started sketching out what a spoiler-safe character lookup would need. The requirements were clear pretty quickly:
Every piece of character data - appearances, life events, relationships, attributes - needs to be tied to a specific point in a specific book. Not just "this character is in Mistborn" but "this character appears in Chapter 3 of The Final Empire as a point-of-view character." Without that granularity, you can't filter.
You need to know where the reader is. That's the reading progress data - which books they've finished, and ideally which chapter they're on in their current book.
And the filtering has to be real, not cosmetic. You can't just hide text behind a spoiler tag and hope the reader doesn't click it. The data from books they haven't read shouldn't be on the page at all.
These requirements were too big and too different to bolt onto a reading tracker. The data model, the contribution system, the curation workflow - it all needed to be purpose-built. So Book Assembly stayed as the reading tracker, and OpenFiction became its own project: a community-driven character database where every piece of data is tied to the story timeline.
The bridge between them
Book Assembly and OpenFiction are separate projects, but they're designed to complement each other. The long-term plan is straightforward: your reading progress in Book Assembly would automatically set your spoiler filter level on OpenFiction.
If you're tracking your reading in Book Assembly and you're on Chapter 12 of The Way of Kings, OpenFiction would know that and filter character pages accordingly. No manual setup, no remembering to update your reading profile - it just works because the two systems share the same understanding of where you are in a book.
The connection would work through ISBN - the universal book identifier. Book Assembly tracks progress by book (identified by ISBN), and OpenFiction's books also have ISBNs. The mapping is clean and doesn't require the two systems to share databases or internal IDs.
This integration is planned but not yet built. For now, OpenFiction has its own reading profile where you manually mark books as read. It works well - the spoiler filtering is live and functional - but the vision is for reading progress to flow automatically from wherever you track it.
Why "open"?
The name isn't an accident. OpenFiction is community-driven by design. The character data is contributed by readers and reviewed by curators. Anyone can add appearances, record relationships, or flag life events. The database grows because people who care about these books put in the work to make it useful for everyone else.
This model exists because the alternative - having one person or a small team manually enter character data for thousands of books - doesn't scale. Fan wikis solved this decades ago with community editing. OpenFiction uses the same principle but with structured data instead of prose, and with a curation layer that ensures quality.
The database grows because people who care about these books put in the work to make it useful for everyone else
The "open" also reflects an attitude. I want to build this in the open - sharing what we're working on, what decisions we're making, and why. Not because transparency is trendy, but because a project like this only works if people trust it enough to use it and contribute to it.
Where we are now
OpenFiction is live with content spanning several major universes: the The Cosmere, Discworld, Middle Earth, Dune, The Culture, and more. The spoiler filtering system is working - set up a reading profile and character pages filter automatically. The contribution system is in place with curator review.
It's early days. The database is growing but there's a lot more to add. Character appearances need mapping, relationships need recording, and there are entire genres beyond fantasy and sci-fi that would benefit from this approach.
If you're the kind of reader who loses track of characters in long series - or if you've ever been spoiled by a wiki - give it a look. And if you'd like to help build it, we'd love to have you.