Hello, I sometimes work as a "sys-admin", meaning i setup and configure web servers and help people to get their software (mostly CMSes) up and running with optimal performances: implying also h.a./clustered/balanced setups sometimes.
I have been dealing with Movable Type in the past year, a platform I didn't have experience with before, because some customers were running it, and I noticed a trend of people moving away from MT, to different platforms (mostly php, notably WP) because they are frustrated by MT.
I thought that I would share some reasons why me (and a lot of people I have helped with their server) find Movable Type difficult to run, manage, and especially scale, hoping that some of my observations will be useful for the future work of SA crowd and the open source community eventually behind MTOS.
If you think this is simlpy a "flame bait" then please ignore me, I spent some time writing this just to provide honest feedback (sorry for my english by the way, is not my first language), and I am not interested to be involved in something like a flame.
So, let me state what I don't like about MT :
1) MT evangelists (including SA vice president Anil's comments on some blog posts). As a matter of fact, people, especially if in a tech role, don't enjoy to hear they are wrong, the software they use and trust is bad coded, and so on. It doesn't seem to me a brilliant "promotion" strategy to tell thousands of sysadmins reccomending wordpress "you are a bunch of dement, MT blows away wp", especially when some of these guys - like me - had a bad experience with MT and actually think the exact opposite.
Infact in these kind of blog posts you always read dozens of angered replies by often extempore wp advocates. Why so much people bother to defend WP ? Because they don't like someone stepping in pretending to know what is better for them I guess.
So, what's my point ? You could rather focus on your real points of strenght, and avoid venomous continued references to other platforms. This way maybe someone - rather than hating your attitude - will decide to try and learn MT as a solution, and maybe learning it they could decide to reccomend the software to some customers/friends, and in the long time they could decide to get involved in community or development and so on: way better than a flame.
I mean, do you expekt that saying to me "you use wordpress, this is cr*ppy software, switch to movable type" will encourage me to reccomend to some of my customers this solution? I especially don't like to hear "we scale better than wp on hi-traffic websites" especially when I had first hand experienced of the contrary. Yes maybe I had a bad experience with MT because I did something not in the optimal way, but you need to realize MT is not easy to run in a optimal way, which leads me to my first real point, #2.
2) It's difficult to install and properly configure and optimize MT. First and foremost a correct Perl environment is WAY MORE DIFFICULT to setup than a PHP installation for most people out there. Perl to most young guys just seems a coding language coming from a dark past age, and little people is interested to learn how it works. So you should undertake big efforts to make your code better working in a lot of different environment taking into account platform differences, AND you should write some documentation about how to check if everything is ok in your perl environment. Cpan is no way friendly and often conflicts with builtin perl modules (eg. in Debian i had big issues).
I googled all the perl errors i have got in the past, and got almost no answer (only dead threads in your support forum, or dead blog posts, with no-one posting a working solution), which leads me to the point #3
3) MT lacks of proper answers and documentation to common issues available on the net. Maybe you do provide a paid support, but if you really want to spread adoption and enlarge the community (which means in turn more plugins, more templates, and so on), you should write better documentation and strive to provide better answers to everyone. Often it seems like nobody encountered your problem before. It's kinda frustrating especially compared to some other software where any error you google you get at least 100 good solutions.
4) If you are interested in increasing MT adoption, you need to provide not only good documentation for the end user but also sample "ideal" setups for sysadmin building a dedicated server from scratch just to run MT. This people usually writes in turn documentation, blog posts, and may as well help end-user adoption. Reccomended configurations, closer examinations about pro and cons of any solution (FCGI, mod_perl, CGI, combination with memcached), virtual machines images to run in vmware player or parallels with ideal software configurations reproduced for everyone to study, and so on. Basically I want to know how you would build your ideal MT setup, if you would use cron jobs or periodic-tools --daemon, or FCGI, and so on, what tweaks you would use in your mt-config, and what would be the reccomended environment to run MT in the fastest way. If a customer comes to me requesting to scale a dedicated server running MT, I could well convince him to migrate to WP, because I feel safer to achieve a working result with it. That's probably my fault that I don't know in depth MT, but if MT was easier to setup in a IDEAL way, i would not need to do so and people would get a better user experience.
In the time I have been able to setup a barely working MT basic single server configuration, I achieved a exotic load balanced WP configuration (like nginx + php-fpm), and I found more documentation for the LATTER on the net.
I could really use some documentation for alternative web servers like nginx or lighttpd, by the way.
If you find more documentation for "nginx+wordpress" (very exotic configurations), than for MT+Apache standard setup, this should trigger a warning bell for you.
5) Scaling. In theory MT should scale better because these are plain .html files after all. An advanced web server like nginx or lighttpd (or apache2.2 not preforked, if you don't need to run php) could serve way more hits without the PHP burden. I guess at least 10 times the hit it would serve with a dynamical CMS, if only static files.
So PHP would seem a problem compared to offline page generation via perl, BUT you won't take into account perl burden that way. Perl load in some specific situations may be WORSE than PHP dynamic page generation.
I am managing a MT blog which can get 500 real comments to a post in a single evening (and several thousands spam ones as well in the meantime). So many comments tend to make static generation unuseful, and the static regeneration process really kills the server.
As I am testing a WP migration for this very blog, and I have already migrated a very similar one earlier this month ( this is the second most popular blog in my country and they were running MT since the early days, and now switched to WP ) I can assure you the same hardware shows HALF of the load with WP completely dynamic (withouth any caching) than with MT (with periodic-tools --daemon support and memcached server in place) in the same situation. And with wordpress comments get published suddenly, while MT often takes more than 30 minutes to have your comment published.
As I am quite sure someone would step in saying "the performance you're seeing are probably the result of a bad configuration", then please again look at point #4. Maybe I run a not ideal configuration to scale MT in such a situation, but again nobody documented it, so I am not able to do any better, and I am migrating to WP even for that blog, banishing MT use just to hi-traffic blogs with NO or few and moderated comments where static .html is actually better.
6) Tried MT 4.2rc2 on a completely idle dual core 2.6ghz new xeon, 4gb ram, raid1 hardware dedicated server with cpanel standard perl configuration. Installation went quite smooth (within the 5 minutes, maybe that's because cpanel is written in perl, so a cpanel server has a decent perl environment well setup). Changed style to another default theme, I click rebuild : 7 seconds reported. Seven seconds to rebuild 3 html pages, 1 post, 1 comment on such a hardware ? Is it normal ?
7) Minor thing: localization should be greatly improved and new languages added at least to have localized basic templates.
I am done. Hope you take this the right way, and find this at least a little useful. Wasted my time otherwise.
No answer? This sounded like a great analysis I think...
I think Gianluca has some very valid points there. I don't agree with everything, but that due to my positive experience. As far as installing MT I haven't had any issues with the servers I've used. I guess I've been lucky (or maybe smart? :p ) when selecting my hosts.
Gianluca raises points which need to be addressed in some manner by "software suppliers" and server hosts, although nobody imagines that the answers are simple or definitive.
Firstly, it needs to be accepted that the people who predominantly use blog/cms/social software are neither coders nor sysops. To imagine so is like thinking that everyone who drives a car is either an engineer or a mechanic. For most of us, we can just about make it back home when something goes wrong simply by using common sense and logic.
MTOS and Movable Type Pro will probably compete mostly with WordPress Mu, Drupal and Joomla! and will be used by people who want to set up communities of users and contributors, which they want to see scale. They will mostly be on shared servers, with the knowledge that they will have to move to some form of dedicated server if things take off.
However, although they may be using either open source or free software and operating in their spare time, the impact of the effort and time put into a project should not be underestimated. They are not under the illusion that they are going to topple MySpace or make a million overnight, but they do want to be able to make a rational judgment before they invest in time and server costs.
The people on the WordPress Mu forums will readily admit that it takes a lot of memory and will not want to live on a shared host for too long. Read the Drupal forums and you will wonder how many plugins you can use before it falls to its knees and whether having yourself and a user logged on at the same time is too much strain. (OK! Please note that that is an obvious exaggeration. Drupal is hot stuff). Joomla! - it would seem - will take the dog for a walk and run you a bath, while simultaneously controlling the whole of planet earth.
I am looking at all of these, along, of course, with MT Pro and finding it difficult to know which way to jump.
To a degree, my expectation is that things will take enough time to get going that either any one of these will develop to have all the things needed, or it will have to be a combination of taking the best bits from each for different tasks.
This still does not make the decision of which one to choose to kick things off with any easier.
I contacted my server hosts and asked which one they thought would have least impact on the server. They gave a non-committal reply (which was reasonable), saying that it would really be revealed when things were being used properly.
I think people really do need to be given some information and ideas on what they can expect when things get beyond themselves being sole user and a few dozen occasional visitors, however imprecise and variable that information has to be termed as being.
PS This is also not a rant. I love MTOS and MT Pro - but do I love it more than Drupal or Mu or maybe Joomla?
@Carlo. You can be lucky, or smart if you would rather define yourself so, to rent your web space with a hoster providing excess capacity on their server so you won't ever notice the shortcomings of the software you are using, but this won't address my point in a number of different situations.
Some people are running big websites and they do run their own infrastructure (their servers) so they need to compare in standard configurations different softwares to make educated decisions ("ceteribus paribus").
They usually can't just throw money to add capacity in something bad working or - worse - bad documented, neither they can just rely on being "lucky".
I have been faced by the though decision - on some very old and popular websites - "to stick with MT and try to optimize it, or to migrate everything to a competing product ?", I have run my own benchmarks, MT was significantly slower and I decided in the end to switch to the other software even on some very old and popular blogs running since 2000-2001.
The fact I have never found optimization/tweaking/best pratices documentation for MT, neither even a single reply here in two months didn't help and it says enough about the so-called MT "community".
Why this fact doesn't help the adoption of the software should be pretty clear: when someone who makes decisions for dozens of different other partners/customers (ie. a system integrator, web consultant, whatever) realizes there's a different software doing a better work, will encourage all of his customers to make the switch, and will never use for a future project that software again. No community and no documentation = no confidence in the software, no adoption.
This were my points and my suggestions. They have been happily ignored, in the same way I happily dismissed MT = win-win I guess, good luck for the future to all of you ;-)