Having yet to learn my lesson, I’m writing another CMS. My go-to excuse is that solving an old problem in a new language is a great way to learn. In truth, learning a new language is just an excuse to try again. When the unsolvable task invariably remains, at least I’ll have something to show for the effort.
It’s just such an interesting challenge. For example, the managed content should be consumable both in a browser and through an API. The input and output of the CMS should be static when possible, but dynamic when necessary. The system should be self-contained, open-source, easily self-hosted, optionally expertly hosted, accessible and extensible, inspirational yet invisible.
From a stakeholder perspective, the CMS should not expect editors to design, nor designers to code, nor developers to acquiesce to its choices. It should gently steer away from the common annoyances of the modern web. At the same time, the CMS should not attempt to be everything for everyone, but instead aim for a near-zero upfront cost to make it a safe default in the typical case.
From a development perspective, the CMS should not feel like a framework that dictates programming outside its purview, nor like a limited service that subs out one problem for another. Instead it should act like a fronting proxy that helpfully and orthogonally chips away at the ever recurring tasks of making a website.