This post is to announce ClipperCMS. ClipperCMS is a fork of MODx Evolution 1.0.6.
Why fork MODx Evolution?
MODx Evolution is an excellent CMS, and the result of many years work by the MODx team, the Etomite team, and many other community contributors.
It is very stable and secure and has a well earned reputation for flexibility. However the MODx team are now developing other CMSs (MODx Revolution and MODx 3) and are concentrating on these. That is their right, and although we are not anticipating using these CMSs ourselves, we wish them every success.
It has been suggested by the MODx team that the community appoint a 'gatekeeper' to liase with the MODx team and coordinate code submissions from the community to MODx Evolution. Whilst we agree that the appointment of a 'gatekeeper' is one possible way to preserve the robustness and security of the codebase, we feel that any development of the codebase should be continued by a group that are independent of MODx, and the 'gatekeeper' (if appointed) should be also independent of MODx.
We have no objections to engaging with and discussing this with the MODx team, if they so wish, but it is a fundamental view of ours that ClipperCMS should be independent of MODx.
Who will develop the code?
This project is in an embryonic stage. Keen contributors are encouraged. The repo is currently at
https://github.com/ClipperCMS/ClipperCMS. Branch 1.1.develop is the main development branch.
Code must be documented, both via comments within the code, and if it is a substantial new piece of code we may expect more comprehensive documentation suitable for end users.
Pull requests should each address one and only issue per pull request. All commits should be clearly described in English. Given the international nature of the existing community, there could be a highly significant role for technical translators.
Before embarking on work, please note that all code submissions are subject to review. We will not automatically include any submission. You may wish to contact us first for a provisional response as to whether the feature you wish to work on is one that should be admitted to the core.
Those who contribute significant code and show a long term commitment to the project will be considered for the core team. The core team is also in an embryonic stage. It is too early to give a definitive description of any organisational structure, but we are aiming for an efficient team with a common ethos that matches the existing nature of the codebase. We are aiming to be genuinely democratic and we do not wish to have a dictator, benevolent or otherwise.
What do we want to do with the codebase?
We do not want to end up with a bloated system.
We will only add new features where a clear demand can be shown, and anything other than core changes would be inefficient or cumbersome. Such new features may well inevitably increase the size of the codebase but our priority is a lean system.
We do not want to break backwards compatibility. We wish to keep the manager recognisable to existing users. Whilst we may well add features, we do not wish to force developers to learn a new templating system or API.
For the same reason we do not want to remove features from the core. Removing features does not necessarily reduce server load significantly if at all, significantly risks breaking backwards compatibility and can increase the workload involved in site upgrades.
Whilst much existing core code has scope for improvement, we do not wish to scrap the whole thing and start again. The current code base is robust and secure and we do not wish to jeapordise that. We also acknowledge that especially in collaborative projects OOP has advantages and as such new code will encouraged to be OO; however we will not be scrapping and rewriting existing good code just to gain an 'OOP' label.
Robustness and security will take priority over features. Contributors will need to provide evidence that the code has been thoroughly tested or to liase with testers and reviewers. For this reason testers and reviewers are sought and we wish to build up an ethos where testers are regarded as being as vital and important members of the core team as developers.
In summary we wish to continue with the existing robust and lightweight CMS that existing users will recognise and be able to seamlessly migrate to.
Are there any other ideas for forking Evolution?
In short, yes.
There is at least one other group currently discussing a fork of MODx Evolution. We were members of that group but left due to doubts as to the direction it was going in. If it succeeds in producing a fork then it is likely to be quite different from the existing codebase, and as such, and as with the MODx team, we wish them all the best.
In addition the Japanese community has developed many clever ideas for enhancing the codebase, and we have spent a significant amount of time looking at this, but we have not yet seen evidence that these have been documented and tested sufficiently to consider them for use on any site on a publicly accessible server. However, subject to the ethos of wanting to keep the codebase lean, and requiring documentation and testing, we are open to ideas from this direction.
We have also seen from few individuals a wish to have a 'MODx lite' (their description) which would be MODx Evolution with many features removed. We do not wish to do this for the reasons stated above, and feel that the aims of efficiency are not going to be effectively furthered by this.
As far as we are aware we are the only group wishing to develop the existing codebase and CMS and keeping it recognisable to existing users.
What will be in 1.1?
We are keeping to the version numbering you will be used to. As such the first release of ClipperCMS will be 1.1.
Most of the changes for 1.1 will be limited to bug fixes and security enhancements.
What will be in the roadmap?
A number of features have been suggested such as multilingual sites fully backwards compatible with existing code, versioning and support for RDBMS other than MySQL. None of these are set in stone as yet and suggestions, especially if they are backed up by reasoning and/or evidence, are welcome.
MODX Staff
MODX Staff
☆ A M B ☆