I think the biggest reason for my decision is the atmosphere of the community. The switch from Etomite to the MODx fork was easy; not only did MODx have all the neat features I wanted, the Etomite community was ... unpleasant. I even had one send a nastygram to a client because the Etomite logo was removed; I had paid Alex for the right to remove it, but the oh-so-helpful community member didn't know that. That was only one specific unpleasant incident; the whole atmosphere was just unpleasant.
The Evo fork community is certainly nowhere near that nasty, but it also isn't anywhere near as pleasant as the MODx community (occasional sniping between me and Jason aside). Ryan especially has overseen the building of a community that I enjoy interacting with, and when it gets down to it, that is probably the biggest selling point for me, since I don't otherwise really have much of a life. The tech is good, and I think in time I'll be able to help make it a bit more practical for the real world, as in clueless clients and their $2 a month hosting plans, and thousands of lone freelance mid-level developers. We can't all be genius or near-genius software engineers working for corporate clients with dedicated servers, after all.
I still have the idea of MODx Light drifting around in the back of my mind, and while Revo won't ever be able to be the core of such a little beastie, what I saw of the way the Evo fork is going won't either. But learning the methods and conventions of Revo will make it possible to create a smaller, lighter version that will be fully compatible. So I'm not giving up on the idea, just waiting until I can see how to implement it.
-
- 24,544 Posts
Well said.
I agree completely and am looking forward to your contributions (and having an ally in my "developers are users too" campaign)
I was actually interested in slimming it down, and putting more things, such as most of the user management features, into optional add-ons. Instead, more is being added to the core. Good things, yes, but still bloating the core. On top of that, everything is being converted to OOP. Now, I've made no secret that I don't really feel that the overhead inherent in OOP is suitable for website development, where server resources such as memory and processor cycles are at a premium. For heavy-duty web-based applications perhaps the overhead is justified, since those would be running on serious dedicated servers anyway. But for 90% of web design it's not justified, at least in my opinion. In the end, I greatly fear that the Evo fork will end up being a poor stepchild of Revo - not necessarily feature-wise, but structurally. The light, quick, easily understood code base that i have loved for all these years is doomed in any case.
-
- 1,098 Posts
Thank you Susan, this is greatly appreciated. My personal opinion is that I would like to include in the manager only the features that are being used on the 99% of websites, and leave everything else as a extra. For user management features do you mean WebLogin PE, the standard Login snippet and MM?
No, I meant the entire user management functioning of the Manager. I would like to see a very simple manager login, with all the groups and resource groups etc optional. I'm undecided whether web users should be incorporated into the basic user system, perhaps role 0. There are advantages to having it a separate system, as well as disadvantages.
-
- 37 Posts
For my additional 3 cents I would say that the most important upgrade for Evo would be to get rid of the 5000 page limit. That way clients with big ideas and projects will not feel limited.
It's been done. Actually it was done some years ago.
☆ A M B ☆
