Some really interesting stuff in here. We are currently a Drupal shop, and it does make commercial sense to nail your colours to the mast a little bit, because supporting one application is easier than supporting five applications. So while at the moment our colours are Drupal Blue, we are always on the hunt for the next big thing. I haven’t tried MODx yet, but this thread makes it very tempting (oh, to have the tiiime!!)
There’s a fair bit of criticism in this thread about the way the Drupal project has been managed, some well founded, some less so. I thought I’d leap in there, not because I have any want to defend Drupal but because many of the issues are still to come for MODx and I think there are valuable lessons to learn.
Firstly, there seems already to be some disagreement/contradiction between contributors to this thread from the MODx community as to whether the MODx core should be bigger or smaller (unless I’m mis-reading). I’m sure that disagreement is yet to make it in to the core team, but as the core team grows it will!
This is interesting, because the same thing has already happened within Drupal. There are those who think core should do EVERYTHING, and there are those who think core should be a light framework. Drupal are in the process of addressing this by having two cores. So-called "smallcore", which will be a very light and not really include any core modules, for PHP developers and another larger version aimed more at people like gspark who don’t want to know about the code, they just want features that work out of the box. (At least, that’s the impression I get from chatting to Rob Douglass at Acquia, who’s fairly heavily involved in smallcore.)
Do the maintainers of MODx have any idea how they intend to tackle this natural tension between the two worlds of developer and designer? Will you continue to produce a core for developers and turn off people who don’t want to get their hands dirty? That in itself would not be a problem, but it will limit your appeal, and thus your community. It would be worth thinking about this problem now rather than waiting for it to bite you in the ass.
2. Then there’s the wider and much bigger issues of "what should be core?" and "how do you manage the code?"
When ifthenelse says of MODx "keep what should be in the core where it belongs", it makes the task sound ever-so-simple. There is also the implication (deliberate or otherwise) that Drupal hasn’t. But what you have to remember is it’s taken Drupal *10 years* to get where it is now. They will always be deciding what should be in the core and that never stops. The technology moves too fast. You can’t sit around a table now and say what should be in the MODx core in 2020.
The reality is the core team of any open source product cannot think of everything that should be in a framework or CMS. Additional features (current examples in Drupal are CCK, Views and Services) *will* inevitably start as contrib and then the core team need to decide whether the contrib should be moved to core or not. This has often been slow to happen with Drupal because core development *is* tightly controlled - it’s not fair to say of Drupal there are "too many cooks". In fact, as an active member of the Drupal community I know just how difficult it is to get changes in to Drupal’s core, and I assure you there are only a few real cooks. Sure, there’s a pile of kitchen hands, but that’s not the same thing. Similarly, there’s piles of contrib crud and you need to be careful what you use, but again, core is tightly controlled.
So where have Drupal gone wrong?
Broadly I think the Drupal management and core team have done a great job, but I do have some criticisms, which I will cite here because it might be useful insight for the emerging MODx guys.
Firstly, over the last few years they have been *way* too slow to move things that should be core over from contrib. I don’t believe this is for any other reason than they were victims of their own success. I think the issue came between Drupal 4.7 and Drupal 6.x. Drupal 4.7 was a huge step forwards and Drupal began to take off, but Dries and the other core contributors weren’t ready for it - nothing was in place to manage the sudden influx of contributions. For a couple of years it was a mess.
Now it is turning. There is strong evidence of structured, reasoned and carefully controlled development of core features in the build of Drupal 7.x. Don’t get me wrong, the effort to get Drupal 5.x and Drupal 6.x out was superb, but it was disorganised and chaotic. That’s why we’re on Drupal 5.19 and 6.13 (!!) and Drupal 6.x was almost a non-starter for anyone on Drupal 5.x already, because the contrib was so slow to catch up. But with 7.x it’s really starting to look slick. For example, there is a sponsored and organised effort to make sure contributors of key modules that are not yet core but are heavily relied upon are ready for Drupal 7.x and have sensible upgrade paths. This did not happen for Drupal 5.x or 6.x, and it damn near killed 6.x for anything other than new websites. Whatever you think of Acquia and the commercial models surrounding Drupal, I would have a good look at how they control core development right now and learn the lessons early. Drupal lost two, maybe three years to problems caused by its own success. Don’t let that happen to MODx. Get the management structures in place now.
The other problem with the management of the Drupal core is a human issue - a tendency to suffer a little from "ivory tower" syndrome. The developers are the managers and I have a problem with this. I am a development manager at heart, so I can’t help myself. I’m not the best developer in the world, but I’ve had a damned good career as an organiser of development resources (and for some big names too) and I know what it takes - so when I join a community I end up trying to shepherd the software a bit too. For example, in the Drupal community I have tried to encourage core developers working on web services integration to work with the Services contrib module team (who are, frankly, miles ahead) but for some reason they won’t do it. IMHO this is simple psychology. I’ve seen it a hundred times. Let me illustrate it with an example from another industry entirely:
When I worked in advertising, it’s crazy the number of times I saw the best writer in the agency (an introverted genius capable of locking himself away in a cupboard for a week and coming out with a set of strap-lines for a series of commercials that blow you away) get promoted to Creative Director (a role that requires sensitivity, people skills, careful political judgement, calm decision making and a thick skin). I think you can see the problem there already. Your best writer will never be the right person to lead your creative team - the required skill-sets are simply not compatible - yet that mistake is repeated over and over all around the world.
The same thing happens with software management. Making your best developers the gatekeepers to the direction of your product is a mistake for the same reason. They’re too close to the project. It hurts too much sometimes to admit they made a mistake and went down a blind alley. It’s annoying to discover you wasted a load of time because someone else has produced a contrib module that does what you were doing in core, only better. The long and the short of it is humans are the problem, because we’re emotional idiots. Whatever you think of "management" (cue Dilbert, etc.) having a layer of people who are disconnected enough to make balanced decisions on the direction of the software is key. Sure, those people need to adhere carefully to the advice given by the core developers, but they need to make calls that a core developer cannot make effectively. They will also consider factors that will not occur to a developer. So I would say to MODx choose your gatekeepers carefully and make sure they are not your developers. Interview them in person. Three times. Treat it as though you were going to pay them $250,000/year to run your corporation. Have dinner with them. Then decide whether you really think they can handle the task or not. They will be the key to having a strong project.
If MODx enjoys the same degree of success, it will also experience all the same issues. My personal take is there are strong lessons to be learned from Drupal. Learn them well and good luck!
(I could’ve tried out MODx in the time it’s taken to write this. Doh!!)
My wife told me to get rid of Jon. Back to no pic. =(
☆ A M B ☆
