Updated: August 2016
Content cat has been in a planning phase for a while, and has had a slight re-organisation for the involved communities structure.
The initial idea is still the same, but it makes a bit more sense to focus the root (www) of this web site for Content Management itself, and not for the CM(S) framework we need for professional Content Management.
This means that the maintenance community for our Drupal 7.x LTS "distribution(s)" will be hosted at a subdomain over at "CMX.content.cat", and the coming community here at the root of (www.)Content.cat will focus on Content Management. We will cover Content Management for both Drupal 7.x (BackDropCMS as base), and WordPress 4.x.
Our primary concern is content. The "system" is a platform, and important, but the productivity tools that let people realise their ideas and dreams are even more important. They demand a flexible and stable environment, that does not keep changing as an ever-moving target that severely limits which efforts are worth pursuing.
A complicating factor for the progress of the establishment of Content.cat related plans, sites and services is EU's new, inflexible VAT legislation for Digital Services such as "premium communities" (read: paid membership communities), as of the new laws that took effect on Jan. 1st, 2015. This makes it difficult to start new projects without taking on too much overhead already from the start. This is being worked on, and interestingly - or even ironically some might say - the Brexit might actually come in handy. We might choose to establish headquarters for this community as an entity in the UK, but there are still legal aspects to confirm first. Eventually we might need to look to establish this entirely outside of EU. We are therefore not yet starting the planned paid memberships, and some related things are on hold and sadly causing delays.
(We honestly thought that given the widespread outcry against that legislation during 2014 (and before), the EU would "relatively quickly" come to its senses and fix this (seemed logical due to the extra high demand for new jobs creation that the whole of the EU region is seeing now during these economically dire times), for example by removing the demand for VAT for operations that has revenue below 100.000 euros or so, like is the case in the UK. But no game - as per spring 2016 this has not happened and new documentation from the EU offices suggest that there will not be any remedy to this until earliest 2018 if at all.)
Meanwhile, over the last year, the development of the "friendly Drupal 7.x fork", "BackDropCMS" has both matured and earned its credibility to the point where also we are convinced that the right strategy for us to move forward is to base our efforts on top of the coming 1.5 release of BD scheduled for September 15th 2016.
(This perspective is being included here on this page right now as a "FYI", although this particular part of our developments now belongs in the not-yet established CMX web site (a subdomain).)
This month (Aug. 2016) we are reaching out to the BackDropCMS.org community with both this information as well as an invitation to discuss how we can best organise our efforts.
As we see it, these are the main elements which will have their own, dedicated community sites as we move on:
- Drupal.org; where the BackDropCMS community also contributes their efforts to prepare things that eventually will be fitted into BD
- BackDropCMS.org; where BD is working on the core development of that CMS fork, but where also the main developer community and documentation exist for inviting more developers to port their existing Drupal/WordPress modules over to BD. However, as the number of modules keeps growing, as we see at the 20.000+ contributed modules at drupal.org, they will NOT be co-ordinated towards playing together in tandem for any particular type of BD setup. We will end up with the same situation there as we already have at drupal.org.
- Here is where CMX.content.cat comes in. We aim to bring in 300-500 contributed modules into our fold, and finance the development and fixes for their compatibility. We want small/mid-sized projects to be sure of their strategic choices and investments, hence we will guarantee staying on the same platform/structure until mid-2020s (roughly the year 2025). That should give small projects sufficient security for their budgeting and competence building. For many projects, we all need a solid, broad base that we have good reason to trust will play nicely together for long time, including security updates. But NOT 20.000+ modules... That is neither useful nor possible. We also need to form sub-groups that focus on certain use cases where specific contributed modules will simply not function or make sense without certain compatibility issues beeing ironed out in related modules. Areas such as mapping, userpoints, premium communities, commerce integration, users/groups security, moderation, taxonomy (re-)organisation, multilingual, revisioning and workflow all need to play well together. It is especially challenging with the overlapping and partically conflicting areas of security/acces control, moderation, workflow and multilingual. The world has not yet seen any mature/stable Open-Source platform that addresses all these aspects at the same time. We are here to do just that.
The CMX community will maintain dediated, pre-configured distributions based on that pool of selected 300-500 contributed modules.
We are also here for the GUI: Even though tools like Drush may proove extremely useful and efficient, the CMX community distributions will make sure all features can be controlled through logical, easy to use GUI front-end as well. We want to help reduce the level of technical knowledge it takes to administer a CMS on a basic level, including setting up the site initially. We should now enter an era where we can approach new projects with the mindset of "virtualization" and "snapshots" so that it is possible to conveniently move back and forth while testing and exploring new things.
Important: These "distros", however, will NOT be made in such a way that they either enforce a specific design, OR raise the bar of competence higher than it is for normal administration of Drupal / BackDrop CORE. We are specifically aiming at avoiding the situation we have with distros such as Drupal Commons (Organic Groups) and the like. Our aim is to let anyone mix and match any theme and also not be locked into learning Panels just to get to customize their site. For example; we are going to provide pre-configurations for Display Suite setups which is much less demanding in terms of technical insight. Panels will also be supported, but our aim will be to guide new admins through such choices and especially outline far-reaching consequences from such choices, and then let them choose which configuration "set" to apply.
We are also going to explore our options in an alternative approach to Features and exportables, in which we may continue with Features and such, but where they will be implemented into the database without depending on continuing using Features, and not as an "enabled feature". After the config choice has been made, the system structure should be updated as if it was done like that from the start without using Features. We are aware of the complexity in this area, and it is likely that this particular effort will spur off a separate project exploring how Artificial-Intelligence-powered Middleware for Database backends may come to the rescue for both WP and Drupal (and more?) based sites.
Ideally, site builders should be allowed to choose their preferred "tool base" first, then on applying it, the distro will shape its configuration based on that, be it Display Suite, Panels or other.
See the Perspectives and Roadmap pages for details, but the fundamentals are now finally in place to enable a community to focus on realising the overused "content is king" notion.
References and resources: