How did WordPress win?
majordojo.com
majordojo.com
There's something to be said for open source packages which work really well out-of-the-box for the vast majority of people who use it.
But oh, my lord, are the internals awful.
It has gotten better over the years, though, I will grant it that.
I guess "no logical sense" is the most legitimate complaint here, but aren't a lot of programs also like that? A lot of things start out one way and end up finding a niche in something different, and that can make the initial assumptions costly and/or annoying, but I don't think it necessarily taints the whole codebase, though.
Maybe I'm old-fashioned but a huge rap sheet of functions is a lot more workable for me than a lot of OO programs that I've had to deal with.
Also, MVC wouldn't make sense for the Linux kernel, but it would make a lot of sense for a major CMS.
If you take a look at wordpress's internals especially nowadays they aren't that bad
If anything I would say the codebase is not bad and the user interface is amazing. I love it because I know that even the least tech savvy of my clients can figure out its backend user interface so they can make content changes themselves.
Another great thing is especially at this point in its maturity you wouldn't need to alter the wordpress codebase itself at all to get most of the value out of it.
Plugins,whether found or written by you, can take care of whatever you need.
Hell, you don't even have to look at the code. Even running some static analysis will tell you how bad it is.
It is still relatively brutish code, but damnit if it doesn't work pretty well.
Until a few (minor) versons ago, some functions built entire translation tables EACH TIME they were called on the same page load. Someone finally caught it recently and put a static in there.
The critical add_action/do_action functions had a slowdown issue up to a few versions ago if there were more than a dozen actions on a filter. It was finally optimized to be hundreds of times faster.
The first time they tried to update the cookie functions for a major release (I think it was 2.5) they misunderstood the research paper and had to change cookies again in 2.6, breaking some plugins twice in two versions.
The meta tables until very recent history were allowed to have non-unique indexes on key values. This "feature" (an alternative to serialization) was almost never used and made meta updates much more complex (and the db slower in general).
The entire tag db structure was changed in version 2.3, breaking all tag plugins, because someone thought it was theoretically better to have a "Term_taxonomy" reference - which is still unused to this date. Having it in there makes tag queries much more complex and slower. Then they took out the timestamp for when tags were added which makes it impossible to track.
The list goes on and on. Remember, a few versions ago is still 2009.
Last time I checked (2.8?) WordPress still uses SQL_CALC_FOUND_ROWS which has some nasty performance problems on many versions of mysql.
To this day, the query count for most pages on a default install with a few posts/comments without plugins is over 20. WordPress 3.1 now uses nearly 1 megabyte of php code PER INSTANCE.
Oh and last but not least, ALL plugins are loaded on EVERY page load regardless of the request/rendering requirements. Even admin-only functions. Clever plugin authors can somewhat code around this but it's still a crazy system.
So far so good, except that upon importing, it creates an entire tree any memory before doing in processing. I complained to Matt about this being a less-than-ideal design. His response was, essentially, "it works for me".
Of course it works for him. He has dedicated servers with gigabytes of RAM. I do not. What I do have blogs with dozens of authors, thousands of posts and hundreds of thousands of comments. Consolidating them on a single installation of Wordpress has cost me days and days.
When I started programming CGI scripts in Perl it was unusual for a web server to be configured to let just anybody write CGI scripts because it was easy to hose a web server or a whole machine with CGI scripts. CGI scripts had a highly inefficient execution model, and no resource limits to prevent CPU and memory overages from bringing the server down.
Now, in principle, mod_perl is better, but practically, a mod_perl installation is rocket science. I saw more than one organization with a crumbling system written in Perl reject mod_perl, because their existing code base wouldn't work correctly in it and because they didn't have faith that they could work all the problems out.
PHP, on the other hand, put a trouble-free installation and deployment experience first, rather than last. PHP might be a crappy language, but an absolute idiot can build a very reliable web server that performs acceptably with no effort. Python, Java, Ruby and other languages are superior in many ways, but they've spent years hacking together deployment answers (with various levels of success) as an afterthought, whereas PHP had performance, reliability and simple deployment baked in from day one.
>The lyrics describe the title establishment as a luxury resort where "you can check out anytime you like, but you can never leave." On the surface, it tells the tale of a weary traveler who becomes trapped in a nightmarish luxury hotel that at first appears inviting and tempting. The song is an allegory about hedonism and self-destruction in the Southern California music industry of the late 1970s; Don Henley called it "our interpretation of the high life in Los Angeles"[6] and later reiterated "it's basically a song about the dark underbelly of the American dream and about excess in America, which is something we knew a lot about."
It's easy-to-start rapidly turns into a tarpit made of sparrow droppings.
(Rails/Django might be a different case, due to the benefits of having an MVC framework as base. But these exist in PHP as well)
There is no reason any code in any language should have this sort of problem. It isn't merely cruft from a long legacy of existence.
For the record, I was the enterprise customer clamoring for ldap support in Byrne's post, and I've since worked for another high profile site built on MT. Its a solid product if you bring a handful of good engineers in on top of it, its just got that "you must be this tall" barrier to entry that makes it an immediate loss for broad-consumer adoption.
I've done a few startups and quite often I will create the marketing front end in WordPress/PHP. Even if the main application will be written in Ruby or Python.
The reason is that there are just so many off the shelf templates and themes you can download and/or buy. And the themes are generally in the under $25 price range. Plus finding people who can maintain a marketing site in WordPress is extremely easy. For the simple stuff like "add a post" or "update the text" you don't even need to know PHP.
Now it would be nice if there was a dead simple platform like WordPress for Python. But until that day comes it is still a pretty damn good solution for a site.
I don't think MT has "weird perlisms", it's just... written in perl. WordPress took off around the time folks were realizing that you could build big sites in PHP, and so PHP in general was taking off (as Byrne mentions in his piece, more enterprise sites were adopting PHP as well). Perl started a slide back into "sysadmin" land as far as many developers and managers were concerned.
Static publishing is not a "quirk": it's a feature that sold MT to most of the large publishers using it. Yes, you have to make some design decisions with static publishing in mind, but I've never heard of an MT site being Fireballed, either.
Cache-only works OK for big sites, but it's annoying for little sites. And the little sites are the big sites of tomorrow.
Wordpress's dynamic-only strategy created a huge pool of potential big customers for Wordpress, and they later tacked on caching. SixApart's cache-only strategy kept a small pool of existing big customers happy, but it was a barrier to entry, and there wasn't an easy path to the ideal "dynamic+cache" solution.
Movabletype did their pay-only nonsense after version 2.66
People starting looking for alternatives.
WordPress 1.5 out and 2.0 was in beta and it seemed the strongest choice at the time. 2004 is like a lifetime for the internet, seems like a poor choice now but things were different then.
Matt and co were very shrewd, had a 'good enough' product and got a few high profile bloggers to switch (and be vocal about it) and WordPress became the common blogger's tool. By the time 2.0 was released it became fairly ubiquitous for blogs, and people added stuff from there to make it a fuller CMS.
Byrne, in his MT-centric worldview, fails to mention a man who contributed more to WP's success than MT's failures could. The name "Matt" only appears within "Automattic" and the name "Mullenweg" doesn't even show up until the comments.
Many have said it and I agree: WordPress is shitty software. Having written a significant percentage of the code in WordPress since version 2.0, I can proudly accept the blame for some of the shittiest parts of WordPress. I was responsible for the integration of the rich editor, the widgets system, the media library, and many other poorly-designed components I have since expunged from memory. I wrote this crap because Matt asked me to.
In wisdom or dumb luck, Matt saw that a feature that mostly works for most users next week is better than a perfect feature next year. He coded as much as he could, then he learned to delegate and trust others. Then, as far as I could tell from inside my coding cave, he shifted most of his attention from engineering and design to promotion and business. He brought Toni and Raanan into Automattic and that's when the switching campaign really took off.
From the early days to now, Matt has exploited every resource for the benefit of WordPress. Even now, non-WordPress Automattic projects help subsidize the core development of WordPress. I don't know how much money Matt has made but I know that everyone who makes a living with WordPress owes him some credit for feeding so much power back into the project.
Matt wasn't the only contributor to the success of WordPress. It would be impossible to cover them all; go look at the About page on wordpress.org to get a taste. But if you could use a time machine to kidnap one person off that list, you would do the most harm to WordPress by choosing Matt.
Byrne says in a comment that his piece is about WordPress, not Automattic. He works hard to avoid delving into personalities. But the story of WordPress can't be told without discussing Matt Mullenweg. If your goal is to "see what lessons can be learned from WordPress so that others seeking to build a successful product can learn from it" you really should be looking at the people and the work they did more than the project that they worked on.
In other words, Worse is Better.
But... many (most?) shared webhosts - which support PHP and WP just fine - run in CGI or FastCGI mode. GoDaddy, IIRC - all PHP is CGI-based. It's been a while since I've done LAMPhp setup, and even longer since that P meant Perl, but it's always felt (as in, going back to 2000/2001) that configuring Apache for mod_php or CGI PHP was just more straightforward than Perl. Reasons?
PHP allows for (encourages?) very 'hack' based approach to development, which most other languages don't. Don't understand how or why to pass parameters around? Just use the 'global' keyword. Rinse, repeat, and you've got your customizations to WP.
I'm not saying all WP mods are hacks, but it was/is very easy for people to experiment with trying their hand and hacking around. IMO this was the biggest thing that has led to WP dominating, and PHP as a language continuing to dominate. Yes, it's not the cleanest around, but it does allow for rapid experimentation (far more than something like Java, and depending on the code you're hacking, Perl).
"""...in fact, if you want to say anything, why don't you run it by me first? And Anil, and through marketing, and while you are at it through a couple other people as well... Cool?"""
Every single issue is about giving maximum control to the users for wordpress. Licensing, easy of installation on almost any host, and language choice. All these said, "Wordpress lets you control your code, where you install it, and how you manipulate it."
In my mind it was a battle of cultures and philosophy. For example, wordpress had the idea of the five minute install. They focused on making the 20% that 80% of users absolutely need as easy as possible.
I'd love to find something in the middle.
(not a troll, genuinely interested)
The expression "Wordpress network" generally means a branded site for these. Wordpress.com is the biggest, edublogs is big too. I run a little one called Ozblogistan: http://ozblogistan.com.au
What a bold bold statement. Care to elaborate why?
'A Free, Open Source, feature rich, easily set up publishing platform is the greatest thing that ever happened to the internet'.
But, isn't that basically what the internet was created for? So it sounds a bit like 'The internet is the greatest thing that ever happened to the internet'. If it wasn't WordPress fulfilling this role, I could easily see another product doing the same thing.
WP makes thing easier and harder for me at the same time. Well I guess its like money, the more you have the more problems it brings. As for the backend, But try WP 3.1, it adds a top bar that was so useful from a plugin i used since 1.5. Also wordcamp rocks.
I don't like the management, but it is a good product.
Just for fun, on what things? I wasn't aware that Matt was so outspoken about any specific thing
Now I don't think socialism is a dirty word, but saying Open Source is socialist is wrong. If anything it's extreme Libertarianist. It's saying if I give you something, you can do whatever the fuck you want with it.
Open Source is not about the government, or any other organization, providing institutionalized software for the good of all.
Open source may be this way, but the GNU (which Wordpress is licensed under) isn't.
The GNU license makes it so everyone is equal. Nobody can have any competitive advantage over another, because as soon as you do, everybody else can now have your code.
You also can't do anything you want with it.
Mind you, I hated it passionately from the first time I was asked to do anything more involved than installing it and switching a theme, and I've never had any inclination to use it on my own time, but I think it's easy to forget that the bar was pretty low when WordPress first came on the scene.