I have been getting a fair number of CMS Made Simple requests lately, and it appears that people are not aware that I am no longer associated with that project. I feel it’s necessary to write this post to clarify the record, and explain why I will not be participating in any future CMS Made Simple related development, attending the Geek Moots, or writing any more books on the subject.
In short, I was losing confidence in the direction of the project. So, on November 14th, when I was asked by the current project leader to resign from the Core Development Team (as an alternative to being thrown off for my lack of participation1), and after 7 years of Core Team involvement, creation of 20-some-odd modules, attendance at four Geek Moots, and writing one of the three books published about the project, I resigned.
The above is all that is important in this post. For my own amusement, I will present some opinions on the future prospects of CMS Made Simple, and, for the people who are asking me about alternative F/OSS CMS software, I’ll provide a few thoughts.
At the time I left, the leadership of the CMS Made Simple Core Team has been involved in creating a non-profit organization to own, fund, and shepherd the project forward. There have been various efforts to expand corporate sponsorship and exclusive promotional relationships with hosting companies. These are all positive developments for the project, and provide the possibility to take it to “the next level.” This organization will still have a few hurdles to overcome for CMSMS to be successful. Here’s what CMSMS will need to do in order to achieve its potential2:
– Steady funding. The nonprofit organization and promotional relationships will likely solve this problem. This will enable the project to have more than one full-time person employed.
– Audience definition. For at least five years, there has been an ongoing battle over what the desired target demographic is for CMSMS. Originally, it was targeted at the small, Mom’n’Pop shop or web designer. The current thinking is that it’s for “experienced web developers.” Similarly, there has been ongoing debate as to how the multilingual community will be best served, and there have been several shifts in direction. For CMSMS to succeed, it will need to have a broad enough target to sustain interest, and a narrow enough target that the team can implement that target’s requirements.
– Overcome architectural limitations. The core architecture of CMSMS is a blend of the “old school” procedural code and weak objects that reveal its roots in PHP versions before 4.3, along with more modern PHP 5 constructs. The limitations that this blend imposes led to the desire to make a clean break, and build a Version 2 with a fully modern architecture. The CMSMS 2.0 project was eventually scrapped, however, as the leadership was unwilling to freeze development and stop adding features to the 1.x version, thereby starving 2.0 of developer resources.
The current approach is an incremental one, with each major dot-release making structural improvements (while altering the API and breaking backwards compatibility). The problem with this approach is that it requires exponentially more work on the part of module authors and the people who maintain sites. For CMSMS to support a modern feature set, however, the older code will need to be rewritten.
– Re-establish and adhere to a plan. At one time there was a road-map laying out feature sets that would be available in subsequent releases. Such a plan guides development decisions and helps ensure that the resources for a project are allocated wisely. This prevents the kind of problem-solving that addresses one immediate problem but creates subsequent problems.
A new road-map would be a positive step to help the documentation problem. It’s just not possible to adequately document a system that goes through changes on an ad hoc basis. With a clear plan, APIs can serve as intended — as a contract with the programmers — and can be documented in a way that’s helpful to both experienced and new users.
– Cement the community. The current leadership of CMSMS has very strong opinions about control of not only the code and the branding, but the conversation about the code and branding. People are regularly banned from the forums or IRC channel for violating rules that forbid talking about core modifications (“mods”) or for failing to follow protocol in asking questions. This comes across, fairly or not, as the Core Team having an adversarial relationship with the end users.
While it’s not visible to outsiders, the tenor of the developer’s channel on IRC was often one of open contempt for end users: there are frequent nominations for “idiot of the day” awards, for example, or the impugning the character of entire nationalities. This attitude is also reflected in slightly more oblique terms on public forums.
To be fair, any Open Source endeavor encounters some definite problems: end users who feel entitled to try to dictate features or demand free work, troublemakers and trolls who will try to tear down a project out of sheer perversity, and people who will complain about any decision that’s made. Projects must find ways to determine which problematic people to ignore and which to engage or eject. A more tolerant CMSMS environment would attract a larger community, which would dilute the power of difficult users (one troll in a small community is a lot more influential than the same troll in a crowd of hundreds).
I’ve had a fair number of people ask me what I’m using for projects, if I’m not using CMS Made Simple code any more. While I can’t go into specifics of projects, I can comment on a few systems that I’ve explored and/or used recently.
Concrete 5 is an MIT-licensed Content Management system with a modern core. It has all of the technical buzzwords I look for like OO, MVC, database abstraction, data objects, user/groups permissions, and jQuery. It has some nice features like a rich core API, safely override-able core files, content versioning, in-context or admin-side content editing, and more. They have a store on the project page, enabling developers to sell add-ons or themes directly through the main page, as well as smart approaches for rewarding community members and contributors of both code and documentation. The Concrete5 team appears to have thought about many of the issues that I consider problematic with CMSMS, and, in many cases, come up with what seem like good solutions.
The Yii framework is not a Content Management System — it’s a development framework. I often used CMS Made Simple as a starting-point framework for a project, since it provided me with a lot of features such as templating, database abstraction, and an authentication system — the content-management aspect was just an added bonus. For heavy development projects, I find the Yii framework to be very well thought out. It’s a modern, MVC-based architecture that has database abstraction, a performant ActiveRecord implementation, authentication and role-based access control, support for AJAXY interfaces, and includes scaffolding and testing facilities to get projects up to speed quickly. Every time I find myself thinking “It’d be great if there was a way to do X,” I discover that Yii has it built in, or has it available as an extension.
The CMSMS project was a significant part of my life for the better part of seven years where I met a lot of great people, made some lasting friendships, and learned a great deal about coding and writing. I hope that this posting is taken in the spirit it is written. I offer best wishes for the project and my friends there; I hope that the CMSMS team is successful and the project flourishes.
1 Actually, I was told that the leadership “would rather that you gracefully resign than our having to have you removed via a public vote.” It might have been entertaining to force a vote, but not entertaining enough for me to actually make the effort.
2 These are, of course, purely my own opinions and should not be construed as anything more. I imagine the current team has identified its own goals and milestones.