This discussion began in a post to the Lyceum Users email list.
Lyceum users,
As many of you have surely noticed, Lyceum development has been essentially nonexistent for the last year and a half. The last point release was a bugfix in June 2008, which is still based on the WordPress 2.0.x branch.
For a lot of reasons, I have not had the time to devote to Lyceum that I used to. Additionally, Lyceum’s primary competitor, WordPress MU, has grown into a respectable and consistently-maintained project. While some users still tell me that they find Lyceum easier to install and in various ways more intuitive than MU, it has more-or-less feature parity with Lyceum…
…except, of course, for the database schema. Lyceum’s schema is normalized, MU’s is, roughly speaking, sharded. For massive installations such as WordPress.com, a sharded schema is preferable. A normalized schema is preferable for everyone else. A normalized schema offers advantages in performance, ease of upgrades and administration, and vast opportunities for developing plugins and features which can access the entire set of data in the installation.
“Show me the last 10 posts across all blogs” is impossible in MU without maintaining and accessing a separate, redundant index table at the application layer. In Lyceum, it is trivial and fast, even for thousands of blogs.
Regardless of these advantages, the effort of maintaining Lyceum must be matched by demand. So I find myself at a crossroads, deciding whether to pick the project back up, or let MU be the only option.
If I choose to resume Lyceum development, here are the two initial phases of development:
Phase 1 - simply bring Lyceum up to the current version of WordPress
I have two options for doing this. The first is to continue developing Lyceum as a branch of WordPress. The second, and more likely option, is to start from scratch using the WordPress MU codebase, keeping all of its features and merely normalizing the schema.
Either way, I could get Lyceum back on its feet in 2-4 months of development. And don’t worry: even though the codebase would be wildly changed, there would be a fully-supported upgrade path from previous versions of Lyceum.
After getting the codebase contemporary with WordPress, applying future WordPress updates to Lyceum would be a non-trivial, but relatively straightforward process. I estimate it would take me an upper bounds of 5 hours of work per week.
Phase 2 - add Lyceum-specific features
There are two main types of Lyceum-specific features that I would like to develop. The first are features which simply leverage the normalized schema — template functions, hooks, utility pages, site-wide feeds… all accessing site-wide content and objects in a way that is easy for template and plugin developers to use without having to worry about the complicated denormalized meta-tables of MU, or the mind-bending (yet fully index-covered) four-table JOINS of Lyceum. (Or any sql at all.)
The second are features which evolve Lyceum into a social platform, connecting content, users, and their online publishing presence in an intuitive and ergonomic way.
I could go on and on about even more things I would like to add to Lyceum — the main theme being seamless integration with other platforms, frameworks, and architectures.
I’ll stop here and let you folks respond.
- What value does Lyceum hold for you today?
- Did you chose Lyceum over WordPress MU mainly because of the schema?
- What do you like and dislike about Lyceum?
- Do you think Lyceum development should continue?
Thanks for any and all feedback, and thanks for using Lyceum!
John
