Byline
Byline CMS
Ver en GitHub

Mission & Vision

Companions:

Why Byline exists

Byline grew out of a frustration that we suspect many projects share. In our experience, many content management systems struggle with at least one of three fundamental concerns: versioning, workflow, or content translation. Some struggle with all three. And when they try to support all three at the same time, the points of tension do not always become obvious until you're deep into a real project with real stakes.

The three pillars

We think about content management in terms of three pillars. We also believe these pillars can coexist without creating mutually exclusive states or unnecessary trade-offs between one and another.

Content translation is not the same as interface translation. The language you write your content in may not be the language you administer your system in. CMS platforms can conflate these concerns; Byline separates them at the data-model level.

Versioning should be immutable and enabled by default. In Byline, every change creates a new version. The current state of a document is a pointer, not a mutation. We treat versioning as part of the foundation rather than as an optional feature.

Workflow should be enabled by default. Editorial workflow is more useful when treated as a first-class concern rather than as an afterthought added through plugins or configuration.

And these three concerns should all work together.

What lets them work together is one architectural decision: Byline separates a document's identity and placement (its URL path, the content locales it advertises, and where it sits in a navigation tree) from its versioned content. Identity and placement live at the document level and stay stable as content moves through drafts and revisions; content lives in an immutable version stream. Keeping the two apart is what stops them from fighting: renaming a slug, re-advertising a locale, or re-ordering a chapter is an immediate structural edit that never resets a document's workflow status or clutters its version history, while every change to the content itself remains a tracked, reviewable version. It is also why provenance holds end to end: versioning accounts for the content, and an audit trail accounts for the structural changes that sit outside it. See Document level vs version level for the full picture.

Data ownership

We believe that if you create and store content, you should be able to get it back out (as obvious as that may sound). Not through an export plugin that sort of works. Not through an API that gives you 80% of what you stored. Your data should be portable, extractable, and workable in full and at any time.

This isn't an ideological position. It's a practical one. We've worked with enough organisations who've been locked into platforms, or who've lost content in migrations, or who've discovered too late that their CMS stored things in a way that made extraction painful and lossy.

We're not trying to be the next WordPress. We're not building a platform that does everything for everyone. And we're not pretending we have all the answers. Byline ships as a stable 4.x release, with meaningful work still ahead.

Building in the open

The developers of Byline have worked extensively with non-profits and NGOs, and this work has shown us the value of certain freedoms: the freedom to own, control, and share content that deserves to be seen. We're building in the open because we think the problems we're solving are shared problems, and because we'd rather build with people who understand them than in isolation.

A note on AI usage in the development of Byline

The core storage model, early UI, and schema / admin configuration system were all developed by hand, drawing on years of experience building solutions on top of other frameworks. Once our core model settled down, and following the 'big leap' in AI coding assistants around December 2025, we have increasingly adopted a 'guided' approach to using LLM-based generative AI to design and plan phases of work. It's been a remarkable journey. The marginal cost of developing Byline has dropped significantly as a result: enough that, with just a 2-person team, we've been able to ship through the 3.x line and into 4.x on our own.

Our hunch is that even within the rapidly evolving world of LLM-based AI, a content management system like Byline will remain a useful tool for our work and for the organisations we support. We're also excited by the potential for building higher-level AI-enabled services on top of Byline. It's hard to predict how this will all play out in a world of software development that is changing fast, though we believe the mission and vision above (along with our note on Content Management in the Time of AI) hold true. Time will tell whether we've guessed right, or not. ;-)